Starting to think about a #p2p social media protocol that doesn't fall foul of the UK's ridiculously broad #OnlineSafetyAct, and leaves what you see in your own hands.
Feed curation as active or effortless as you like, using whatever approach you choose.
So a protocol that provides the basis for user respecting apps with different approaches.
Goal: curation with zero effort via support for 'algos' that serve you rather than the other way around.
@happyborg maybe don't go new school (LLMs). Go old school. UUCP, netnews. Clients, servers, transports, message formats already there. Nothing to invent. Done.
Then for privacy you simply encrypt (where it will not lead to a trip to a room with rubber hoses) with, say, GPG using web of trust (no hierarchal PKI).
But the real problem is not technical (protocols), but social (laws, snoops, hackers, marketing...)
@eludom I believe in #p2p, not client servers. For me, servers are the core source of pain: vulnerabilities, centralisation etc
You are free to solve the issues you see the way you want, but it's pointless trying to get me to adopt your approach when it is based on incompatible beliefs.
@happyborg The pre-Internet architecture of UUCP/news was more p2p-ish (still viable). Any two nodes connect to each other and basically assert "I have [message-id]" at which point the other end has the option of saying "Sent me [message-id]". It was [is] "flood and fill".
It only became client/server with the advent of large centralized repositories (UUNET, later Google), NNRP and the like.
@eludom UUNET is something I used back in the day.
I doubt very much that, like TCP/IP it was a complete and adequate protocol.
My focus is here and now.
I may look at existing approaches such as #XMPP and #Nostr for comparison, and perhaps even #UUCP now you mention it but I have limited time and won't make progress if that's all I do.
You suggesting UUCP as a solution to today's problems isn't convincing because first I want to hear from you, what problems and how it solves them.
@happyborg the transport is actually irrelevant. Could be UUCP, TCP, QUIC, some kind of local phone-to-phone communication (NFC?, bluetooth?) ... does not even have to be connection oriented, broadcast will do.
The core bit that I think is reusable is the flood and fill architecture.
But, as I said, I think the core problem is social, not technical.
Add comment