Yes this is a great discussion. Generally speaking I see how user local-first posting mirrored by relays under e2ee can help solve some of the downsides of instance based federation, however it seems like the actual implementation makes or breaks the utility.

I have a concept that came up in reading the comments on lobster, which is that the issue of incomplete data due to asynchronous/intermittent downtime push and pull by users to/from the relays as well as inconsistent relays behavior leads to inevitable incomplete/non-consensus/out of date data access (something federation also suffers from).

My idea is that relays, bothe standard and specialized, could host a dedicated encrypted ledger for each user/key that has posted to it (potentially within a time limit, or with approval) that holds only a sequential identifier (counted since the first event by the key) of the user's most recent activity and a unique identifier/key associated with the event the activity was associated with (so that edits would be associated with the UI of the post being edited for example, or a new message to an ongoing thread would use the UI of the thread and the UI of the message.) Limit this log to very few entries and replace it every time it is updated, say between 1 and 10, and you would keep the size of the file very small, and the pushed update from the user/key would also be very small.

This way a user could push activity log updates to a broader set of hosts/relays than the actual content/event was sent to while keeping the cache/data burden on the broader network down. Ideally this would mean that not only the Relays but also users following the user/key could hold the log (enabling gossip without large cache burden). Unlike a blockchain where the ledgers would need to cross-sync with each-other and seek consensus on larger data chunks, in this case the reader of the ledger can always default to the most recent sequential identifier, and that identifier would be generated by publishing key/user.

This way time code variance isn't an issue, and at time of login a user can pull the logs for all users/keys they follow from relays OR peers they follow and determine the number of events posted by each user/key since they last pulled updates. Then the client could crawl the relays for the actual events with sequential identifiers between those AND stop crawling once they are found.

One issue I see with this sort of system is in the case of deleted events, so perhaps the log would also need to include a string of the sequential identifiers of events which have been deleted within a given time period.