I did the survey but please would you mind identifying yourself and linking to the research paper when it’s ready?

Does OrganicMaps have editing abilities?

signal is designed not to trust the server

Unfortunately this is not enough. A malicious Signal server can mount a timing correlation attack and infer the social graph of an user. Having a centralized server makes it more difficult to mitigate such risk.

Then yes there’s EEE danger. Hopefully the Mastodon developers will resist that.

Unfortunately developers can do very little to prevent that. EEE works by first attracting a large userbase into a service and later on prevent them from leaving. It’s up to instances admins and users to defederate to prevent EEE.

This is debatable. The GPL allow redistribution of a given version of the software without additional restriction. If the user receives that copy knowing in advance that redistribution will lead to retaliatory actions this can be treated as an additional restriction.

Here’s a summary: https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html

That’s besides the point. Of course it’s always possible to create new communities on new instances, and import posts from various sources, but the original community would be still gone.

If an instance is shut down or becomes unusable for a long time there is no way to automatically migrate users to a new instance. Additionally, there is also no guarantee that all users will move to the same alternative instance. This can also cause unnecessary conflict around which alternative instance becomes the “legitimate” successor.

This is not correct. APT always verifies cryptographic signature unless you explicitly disable it. Yet it’s very important to understand who is signing packages. What kind of review process did the software go through? What kind of vetting did the package maintainer themselves go through?

If software is signed only by the upstream developer and no 3rd party review is done by a distribution this means trusting a stranger’s account on a software forge.

Update: the Debian infrastructure supports checking gpg signatures from upstream developers i.e. on the tarballs published on software forges.

What you are describing is just a local cache of !lemmy@lemmy.ml on your instance and it works only if it has been populated before the downtime of lemmy.ml. If lemmy.ml never comes back to life nobody can post to !lemmy@lemmy.ml proper. All the communities on in would be dead.

Context is important. It’s possible that the software is distributed without any warning like that and that the termination of the support contract is done without citing the redistribution of previous versions as a reason. OTOH if the customers could prove that there’s widespread knowledge of the retaliatory termination that could be equivalent to a (non-written) restriction that is indeed incompatible with the GPL

Terminating a support contract, in itself, is not a GPL violation. The restrictions only affects the ability to receive future updates.

Edit: Red Hat indeed claims that no GPL violation is happening, yet they inform their customers that sharing updates leads to contract termination, which clearly breaches the GPL at least in spirit: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/

This is not a communication problem. Communities are indeed centralized and if an instance is shut down permanently or loses its data all the communities are gone. This is a big design problem of Lemmy.

Edit: it’s sometimes possible to rebuild new communities on another instance and recover past messages that have been replicated on other instances (if there were full replicas) but this requires all users and moderators to agree on where to migrate and avoid splits and so on.

Please do now upvote techrights.org - they use hyperbolic tones and produce clickbait.

It’s in no way “everyone”, just a vocal minority.

Indeed PostgreSQL is not designed for large scale horizontal sharding with eventual consistency. Also ClickHouse is designed for OLAP workloads likely making it even less suitable.

Regardless of database choice, Lemmy is still centralized. Discussion groups are cached across instances but not truly distributed. This is the big blocker.

If say lemmy.ml is down, what’s the point of other servers existing, if most of the content and users are here?

There is no replication and failover so the problem is not solved.

blockchain technology

Urgh, no way. Replication and some basic message signing would be enough.

Indeed. If a big instance like lemmy.ml was to be shut down all the communities would be lost. This is simply not sustainable. Why would users put effort building a community if it could be gone at any time?

What you are describing is just a form of “remote following”, which is merely local caching of some content from another instance. As you wrote, each @gaming is an entirely independent community, even if the moderators are the same people across multiple servers. If an instance is shut down the community is gone. If the instance decides to throttle access and start charging money users have to pay or abandon the community. In short, this is not a significantly better user experience than traditional online forums. I’d rather have real federation.

Unfortunately that breaks the concept of federation. I expected servers with good relationships with each other to replicate posts, otherwise what’s the point of federation?

My bad, I got confused by https://codeberg.org/calckey/calckey/issues/3235 - thank you!