Cooper8

Followup question: is there a company that is not part of the new lighting cartel making screws-in bulbs that actually last 10+ years?

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.

My understanding is that the content is essentially self-hosted, so content removed from relays still exists on the posting user's client and can be accessed directly, just like a website sending out RSS. So saying it "still exist on the network" is technically true, but only in the same way that you would say that about say bittorrent or the open web. What people host/post is present raw, what is amplified/"curated"/relayed is filtered. Client settings/config sets default and custom user content interaction, like a browser which can have adblock or not.

In principle, this seems like a decent solution, but I can see why different users prefer different protocols, differing to moderation takes a burden off of the user to vet inbound content. The same can be achieved via relays but the culture of "curation" seems weaker because the pressure from the userbase is lower to optimize it, as users are not solely reliant on any one relays. An odd network effect, but a truly invested curation/admin team could just as easily build a well "curated" relay as a well moderated instance.

This is helpful thanks, seems like ditto is an interesting middle ground.

maybe Peergos? I'm not sure, seem to match up on Goals but IDK about execution: https://github.com/Peergos/Peergos?tab=readme-ov-file

Sounds a bit like Plebbit, though that is more about P2P "communities/boards" that a user starts and others can post to, rather than a microblog type platform. Unfortunately it also has a strong association with Crypto communities as its founders come from that scene. It is built on IPFS.

What you describe also has similiarities to Secure Scuttlebutt and its successor PZP , which are both unfortunately abandoned but layed a lot of groundwork for asynchronous encryption key based networks.

Vlogbrothers ftw

Client-side curation sounds like whitelisting effectively, if you follow only the curated feed and the curated feed resigns all events posted by selected keys, that's a whitelist and seems like a decent solution for casual users so long as they can find trusted curators and clients that enable them to be easily discovered and subscribed to. What client is best for this currently?

On the flipside, if those "curators" were able to export and import lists of keys to automatically exclude from feeds, that would be very useful for the curators who have to manually or automatically sort events and new users to build their feeds. Is that feature currently available? Eliminating known bot accounts from feeds seems like minimum viable feature set for new curators in the current state of play.

So there are no moderation tools / whitelist/blacklists?

What do you prefer about Nostr?

The question is why is this the case? The simple answer is p2p solutions struggle with asynchronous communications due to variable uptime of consumer devices. That said, that can be overcome by various means.

Establishing a user base for any communications platform is a challenge, largely adoption is driven by user experience and project narrative. There is no reason a p2p project couldn't meet these criteria, they have before many times for file-sharing.

In fact, I think a self-hosted cloud storage solution with a communications platform built on it could be a great way to get a network of this type established. I know various file-sharing platforms like Soulseek have had these features, but I wonder if you slapped a WhatsApp clone UI onto it and push it as "own and share your files securely, no one you don't specifically share the file with ever holds the files" if that wouldn't pick up some steam.

Sadly Secure Scuttlebutt Protocol is abandonware, as is it's more scalable but far less tested successor PZP

The p2p social approach seems so necessary, but projects that actually implement it are fraught with challenges it seems.