I think talking about federated services is different from talking about federated data. In Lemmy they are the same, which is why it’s not a good architecture. In Usenet they were not the same, but outside of mammoth technology there’s no similar solution.

Think about bittorrent trackers. They do serve the job of helping peers find each other. But nothing is tied to them, mostly, outside of many closed ones.

Lemmy instances also provide storage and relay services, functionally.

All of these can be separate, and user identities can be untied from instances of some service.

Trackers help you find relays and storage nodes serving specific users and groups. User and group identities are cryptographic (hope so, but one can have separate authentication services, why the hell not ; then it may be analogous to Lemmy instances in regards to bans and moderation).

Doing that isn’t easy, though. But I suppose a competent programmer can implement a tracker (simplest by far - announce, clear, request and storage, the tracker just has to check signatures if identity is, say, hash of public key), a storage service (an object storage with authentication, similar to previous, but perhaps paid with additional registration for that identity), a relay (not much more complex than a toy chat server, but perhaps similar to storage service) and a client application (that one is complex, but not too much, because all the logic of finding stuff by trackers and assembling\replaying group\user\post states is on the client) in not too horrible time.

OK, I’ve started writing a prototype for that in an TCL/Tk recently, lost willpower (ASD, BAD, bad sleep, bad food habits) after adding replays and before adding networking, and when thinking about convenience of integration with ready libraries and such, suspect C or C++ from the beginning would be easier. Bitwise operations not being PITA as a bonus.