Also apologies. If you want to chat to me in more ~realtime, I'm more active on something we're calling Parley -- A truly decentralised federated IRC chat system. You have to spin up your own instance (ideally) or join someone else's, but otherwise you use a normal IRCv3 capable client, but the entire "network" (so to speak) automatically forms a decentralized mesh.

👋 Calling all decentralised enthusiasts that still remembers and use IRC 😎

Please come join us in a new, truely, decentralised IRC-based chat experience by standing up your own Parley instance on your own domain (bring your own OIDC auth or use the built-in).

Pick your favourite IRCv3-compatible client (there's heaps out there!).

And peer with either me james@mills.io or Admin -> Peers -> Add mills.io or @david via david@ratha.us or simply ratha.us (in Admin -> Peers -> Add).

See you online! 🤞 #decentralised #irc #chat

I have (finally) built a fully e2e working purely decentralised and federated IRC-compatible chat server. It is currently a PoC, but it's already working quite well. It's inspired partly by the work we did with Salty Chat in terms of Discovery and Federation. Some screenshots of a normal IRC client irssi showing off how it works in a local e2e setup:

Does anyone have time this weekend to manually test and validate and prove out this spec I'm calling Gitxt? A Twtxt-inspired purely decentralised Git federation/forge? 🤔 Hit me up! You need only git, curl and a web server of some kind.

gitxt is a purely decentralised git forge. There is no federation protocol, no instance-to-instance API, no accounts on other people’s servers. Each forge instance is fully independent; collaboration is an act of publishing and reading plain text files over HTTP

@fossham I honestly think the most unique and interesting thing about doing this at all is that it is in fact inspired directly by Twtxt / Yarn.social itself -- That is to say, I am confident I can do this in such a way as to be "truly decentralised", no inter-networking like ActivityPub, no centraised forges like Github or Codeberg. You run your instance, I run mine, we just are able to collaborate. Think exchanging patches over Email, just without all the hard-to-learn ways to do that (enough though it's not hard for some of us, but still).

@movq In the meantime tell me all your "wishes" and things you wish/want a good decent "pure" decentralised Git forge should do 😅

@arg You actually can, but we highly discourage it and I haven't really built "Edit" / "Delete" functionality in the Twtxt App that I know you're using 😅 Twtxt being purely decentralised, meaning that there are absolutely zero decentralised, with the exception of the twtpub.com service you're using to reduce as much friction as possible for newcomers to try things, makes supporting threads a bit of a controversial topic 😆 -- In the end we are sticking with the Hash v2 extension, making threads use content addressing, so even if you did delete/edit a Twt, you have to be carefuly it hasn't already been replied to in the ecosystem 🤣

The only place where this would be an issue is the Twtxt Search Engine -- But as the GDPR also points out:

Art. 17

The one place the "it propagated and I can't recall it" problem is legally acknowledged is Art. 17(2), and it explicitly scales to what's technically feasible:

"…the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure…"

Best-effort, given the technology. A decentralised, append-only, content-addressed feed is the available technology, and its limits are baked into the standard the law applies. Nobody — not the user, not you — is obliged to guarantee every cached copy vanishes.

twtpub.com is just the default instance tho — it's a multi-tenant twtd, AGPLv3. Run your own and I'll list it in the app's picker so folks choose where to land 🤗 keeps it decentralised + spreads the load. Docs → https://git.mills.io/yarnsocial/twtd

And speaking of Twtxt (See: #xushlda, feeds should be treated as append-only. Your client(s) should be appending Twts to the bottom of the file. Edits should never modify the timestamp of the Twt being edited, nor should a Twt that was edited by deleted, unless you actually intended to delete it (but that's more complicated as it's very hard to control or tell clients what to do in a truely decentralised ecosystem for the deletion case). #Twtxt #Client #Recommendations