[southerntofu]

> some reasonable (against forks using their servers) (...) justifications

How is that reasonable in a centralized client-server model? That's precisely what we find unreasonable with Twitter and others shutting down or making life hard for 3rd party clients. Why would it be more acceptable from a free-software service?

The network effect says a centralized protocol like Signal has "zero" value without reusing the same servers. All this because Signal maintainers have an ideological argument against decentralization, which received many great responses including this one from a Jabber/XMPP client developer: https://gultsch.de/objection.html

In all cases, Signal servers control who has an account, what permissions and what can be posted. You can't just extend the protocol to enrich your client by abusing Signal's servers, but you can make your client compatible with Signal protocol (interoperability). Preventing that is rather user-hostile.

[Abishek_Muthian]

You are asking some very pertinent questions.

The reason why I felt there's some reason to Signal's stand on forks was because forks not standing up Them having their own F-Droid repository is to the quality standards, not adhering to feature parity while consuming their resources might not go well with their funders.

Signal having its own repo on F-Droid is the viable solution for them but they don't seem have any intention of doing it.

I don't agree with Moxie's reasoning against federated technologies, TBH I prefer email over any real-time communication due to its federated nature.

[southerntofu]

> the quality standards (...) feature parity

F-Droid community was interested to package Signal but at the time upstream had a hard dependency on Google Play Services (which according to my/F-Droid quality standards is pretty bad), and made it clear they didn't want any unapproved builds using their servers. This would include reproducible builds from the same source code as is standard in F-Droid official repo. Still, such builds would hypothetically have the same quality standards and feature parity with upstream.

[Abishek_Muthian]

I agree, Even the standalone apk which can use web sockets for notifications still has Google Play Services and so the F-Droid repo should be a separate code base without GPS.

Btw it seems I had a brain fart when typing this -

>The reason why I felt there's some reason to Signal's stand on forks was because forks not standing up Them having their own F-Droid repository is to the quality standards...

The reason why I felt there's some reason to Signal's stand on forks was because forks not standing up to their quality standards...

[southerntofu]

> still has Google Play Services and so the F-Droid repo should be a separate code base without GPS

A simple/single F-Droid patch could be enough.. Such a simple change doesn't have to be a huge maintenance burden.