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:

@itsericwoodward Don't worry, we'll tell you rather loudly if your client is misbehaving or your feed is down 🤣

@movq Ahh, no you can. Much like what we've built here with Twtxt / Yarn. I'm building a spec, clients can implement the spec, or you can ya know, just curl and git your way through. I'll link the spec soon™, just need to keep refining and testing and make sure this actually works properly 😅

@Sumomo I haven't heard of that client before? 🤔 Got a link to it? screenshtos? Should I add it to the Listed Clients? 🤔

@Sumomo Ahh if you're using the 'ol twtxt client from buckket, that thing isn't really maintained anymore. I recommend you check out one of the clients listed on https://twtxt.dev or even just https://twtxt.app

@Sumomo What client are you using btw? 🤔 Does it support threads, and other v2 specs? 🤔

@brytboi I mean you can, technically. But most clients won't render Javascript or HTML fragments at all. Only Markdown, Text, Images and Links.

I really do find it difficult to follow anyone that basically posts to a wall, or doesn't follow back. It's utterly pointless not being able to have a conversation, like basically, at all. Maybe it's not even anyone's fault? Maybe just a sucky client that doesn't understand how User-Agent works in Twtxt Discovery? 💡

it's client sue not on any publishing backend

@movq @lyse Are you clients remaining compatible with Hash v1 in case older clients are still well not upgraded? 🤔

@david well I happen to agree because one of the fundamental problems is that you can't have a tax file specification and assume that you can edit it freely by hand as a human and then clients that deal with that specification in machine possible mechanisms the two kind of conflict because humans get things wrong machines don't

I don't think I'm going to add edit and delete support in this app because I think it was a horrible mistake to add those features to a client 🤣

@movq please don't waste your time to bugging this. I'll figure out what's going on with these new clients.🙏

Fixed the broken hashes in the Twtxt App (https://twtxt.app) 🥳 It was hashing your twts with a client-side timestamp the server never used 🤦‍♂️ Now it keeps the canonical created/hash the pod (or twtd) returns, and the GitHub/Gitea backends write a # url = preamble so every client hashes your feed the same way. Thanks @fastidious for the report 🙏

@bender Please create an issue for this too! Probably against twtd right? We should validate new fetchers and see if they are real clients or not. I think yarnd already does ybis quite well? 🧐

Oh if we're talking about the twtxt.app client, that's a different story. I still consider that alpha/beta quality. Lemme look into that. It has it's own cache of course (using IndexDB) and it's entirely possible some behaviours are still not quite right yet...

@GabesArcade Wiath what client? 🤔

@GabesArcade's Arcade@gabesarcade.com You will want to either build a client or use one of the ones listed here -- Either way you choose! 👌 I just noticed as well in this Twt I'm replying to (threading is a thing™) that you @-mentioned @bender incorrectly 😅

👋 Looking for other interested folks to continue to evolve the development of Salty.im 🙏 I've been hard™ at work on the v2 branch and @doesnm.p.psf.lt has been incredibly helpful so far. Be great ot have a few more folks to join us, some of the v2 highlights include:

• Double Ratchet by default.
• Group Chat (sender/client fan-out for now)
• Much better TUI with background agent.
• Mobile App coming soon™ (iOS in progress, Android next, same codebase)

I spent the day today integrating @xuu's double ratcheting work and [ratchet](Blank front page) library back into the reference client/broker implementation saltyim as a v2 branch. I completely redesigned and rewrite the salty-chat TUI client as well, which now includes proper notifications and a background agent that keeps running so you never miss any messages. It all "just works"™ and I'm quite happy with the outcome! 🤩 #saltyim #revamp

I keep getting this email occadionally:

Your iCloud storage is almost full

Now for various reasons, I don't want my children to be using iCloud to store data, files, photos or any of the sort. They're free to use iMessages, and other Apple services like the App Store, etc, but not storage.

So I've set about blocking iCloud Storage API(s) via AdGuard Home tonight as well as ensuring that my local network (client users) cannot bypass DNS policies and get out other sneaky ways, because some applications will just use other DNS servers, or DOH or DOT.

TNO Threading (draft):
Each origin feed numbers new threads (tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).

• Roots: (tno:N) (implicit ofeed=self).
• Replies: (tno:N) (ofeed:<url>).
• Clients: increment tno locally for new threads, copy tags on reply.
• Subjects optional, not required.

...

Finally I propose that we increase the Twt Hash length from 7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update

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

Just like we don't write emails by hand anymore (See: #a3adoka), we don’t manually write Twts or update our twtxt.txt feeds. Instead, we use modern Twtxt clients that conform to the specifications at Twtxt.dev for a seamless, automated experience. #Twtxt #Twt #UserExperience

Nobody writes emails by hand using RFC 5322 anymore, nor do we manually send them through telnet and SMTP commands. The days of crafting emails in raw format and dialing into servers are long gone. Modern email clients and services handle it all seamlessly in the background, making email easier than ever to send and receive—without needing to understand the protocols or formats behind it! #Email #SMTP #RFC #Automation

$ bat https://twtxt.net/twt/edgwjcq | jq '.subject'
""

hahahahaha 🤣 Does your client allow you to do this or what? 🤔

Interesting factoid... By inspecting my "followers" list every now and again, I can tell who uses a client like jenny, tt or any other client where fetches are driven by user interactions of invoking the app. What do we call this type of client? Hmmm 🤔 Then I can tell who uses yarnd because they are "seen" more frequently 🤣

💡 I had this crazy idea (or is it?) last night while thinking about Twtxt and Yarn.social 😅 There are two things I think that could be really useful additions to the yarnd UI/UX experience (for those that use it) and as "client" features (not spec changes). The two ideas are quite simple:

• Voting -- a way to cast, collect a vote on a decision, topic or opinion.
• RSVP -- a way to "rsvp" to a virtual (pr physical) event.

Both would use "plain text" on top of the way we already use Twtxt today and clients would render an appropriate UI/UX.