Searching txt.sour.is

Twts matching #Twt
Sort by: Newest, Oldest, Most Relevant
In-reply-to » 2024 was okay for me, but 2025 is gonna be real shit. 😂 So much annoying stuff coming up. Gotta enjoy the moment, who knows how long it will last. 😅

@bender@twtxt.net @aelaraji@aelaraji.com Sorry this was my fault 🤦 For whatever reason my pod had never seen that particular Twt from @movq@www.uninformativ.de – And… There’s a bit of a “behavioral” problem with the Trusted Peers functionality that means operators have to periodically re-trust peers manually 😭 Need to rework this 🤞

⤋ Read More

hey @prologic@twtxt.net heads up - my pod is suddenly having weird 400 bad request errors on things like posting twts, new user registration, following, and more. it’s not just me because a friend is also having these issues as a new user and can’t post. i saw one exception in the logs but i’m not sure if it’s related, i’ll link it in a reply to this

⤋ Read More
In-reply-to » I'm thinking of bringing back filters (this time not as a feature flag, just baked in): New filters: Hide Feed, Hide Bots, Hide News, Media Only, No Replies, Local Only — toggle to trim noise & surface the Twts you care about.

I’m also thinking of adding eye-off icon next to every Twt that, when clicked, hides that feed (tooltip: “Hide this feed”). This would work with the filters as a “temporary additive filter” to restrict/control the current view.

⤋ Read More

I’m thinking of bringing back filters (this time not as a feature flag, just baked in): New filters: Hide Feed, Hide Bots, Hide News, Media Only, No Replies, Local Only — toggle to trim noise & surface the Twts you care about.

⤋ Read More

last night my timeline randomly reset to only show my own recent twts and i restarted my instance a few times and pulled from main and shit and it didn’t change but it seems fine now lol?!

⤋ Read More
In-reply-to » @andros Thanks for consolidating a lot of good ideas. Especially how you have deiced to just extend the mention syntax for location-based treads. This might even be backward compatible with older (pre-yarn) clients. What about using Z for UTC +00:00- is that allowed in your specs? Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !? I'm still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.

In other words, why didn’t you all do the same that @movq@www.uninformativ.de did, and setup a completely different feed for this?

⤋ Read More
In-reply-to » @andros Thanks for consolidating a lot of good ideas. Especially how you have deiced to just extend the mention syntax for location-based treads. This might even be backward compatible with older (pre-yarn) clients. What about using Z for UTC +00:00- is that allowed in your specs? Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !? I'm still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.

But Yarn does not like it: https://twtxt.net/twt/yoatzwa

⤋ Read More

I’ve just released version 1.0 of twtxt.el (the Emacs client), the stable and final version with the current extensions. I’ll let the community maintain it, if there are interested in using it. I will also be open to fix small bugs.
I don’t know if this twt is a goodbye or a see you later. Maybe I will never come back, or maybe I will post a new twt this afternoon. But it’s always important to be grateful. Thanks to @prologic@twtxt.net @movq@www.uninformativ.de @eapl.me@eapl.me @bender@twtxt.net @aelaraji@aelaraji.com @arne@uplegger.eu @david@collantes.us @lyse@lyse.isobeef.org @doesnm@doesnm.p.psf.lt @xuu@txt.sour.is @sorenpeter@darch.dk for everything you have taught me. I’ve learned a lot about #twtxt, HTTP and working in community. It has been a fantastic adventure!
What will become of me? I have created a twtxt fork called Texudus (https://texudus.readthedocs.io/). I want to continue learning on my own without the legacy limitations or technologies that implement twtxt. It’s not a replacement for any technology, it’s just my own little lab. I have also made a fork of my own client and will be focusing on it for a while. I don’t expect anyone to use it, but feedback is always welcome.
Best regards to everyone.
#twtxt #emacs #twtxt-el #texudus

⤋ Read More
In-reply-to » If we must stick to hashes for threading, can we maybe make it mandatory to always include a reference to the original twt URL when writing replies?

@lyse@lyse.isobeef.org Kind of, but on the other hand: This twt right here refers to 3rvya6q and your feed, but your feed certainly does not include that particular twt (it comes from my feed).

But my proposal probably isn’t very helpful, either. We have this flat conversation model, so … this twt right here, what should it refer to? Your twt? My root twt? I don’t know.

@prologic@twtxt.net Don’t include this just yet. I need to think about this some more (or drop the idea).

⤋ Read More
In-reply-to » 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

that said, and reading to @sorenpeter@darch.dk and @andros@twtxt.andros.dev I have new thoughts. I assume that this won’t change anyone’s opinions or priorities, so it makes no harm sharing them.

It’s always tempting to use something that already exists (like X, Masto, Bsky, etc.) rather that building anything through effort and disagreement until reaching to something useful and valuable together. A ‘social service’ is only useful if people is using it.

I’ll add that I haven’t lost interest on the ‘hacky’ part of twtxt about developing tools, protocols, and extensions as a community. It’s the appealing part! It’s a nice hobby to have, shared with random people across the world.
But this is not the right way for me, and makes me feel that I’m unwelcome to propose something different (after watching replies to my previous twt). Feels like “If you don’t agree, you are free to leave, we’ll miss you.” Naah, not cool. I’ve lived that many times before, and nowadays I don’t have enough spare time and energy for a hobby like that.

Let’s see what happens next with the micro-community!

⤋ Read More
In-reply-to » If we must stick to hashes for threading, can we maybe make it mandatory to always include a reference to the original twt URL when writing replies?

@prologic@twtxt.net Not sure I’d attach any if clauses to this. My point is: Every time I see a hash, I’d like to have a hint as to where to find the corresponding twt.

⤋ Read More
In-reply-to » If we must stick to hashes for threading, can we maybe make it mandatory to always include a reference to the original twt URL when writing replies?

@movq@www.uninformativ.de If we’re focusing on solving the “missing roots” problems. I would start to think about “client recommendations”. The first recommendation would be:

  1. Replying to a Twt that has no initial Subject must itself have a Subject of the form (hash; url).

This way it’s a hint to fetching clients that follow B, but not A (in the case of no mentions) that the Subject/Root might (very likely) is in the feed url.

⤋ Read More

If we must stick to hashes for threading, can we maybe make it mandatory to always include a reference to the original twt URL when writing replies?

Instead of

(<a href="https://txt.sour.is/search?q=%23123467">#123467</a>) hello foo bar

you would have

(<a href="https://txt.sour.is/search?q=%23123467">#123467</a> http://foo.com/tw.txt) hello foo bar

or maybe even:

(<a href="https://txt.sour.is/search?q=%23123467">#123467</a> 2025-04-30T12:30:31Z http://foo.com/tw.txt) hello foo bar

This would greatly help in reconstructing broken threads, since hashes are obviously unfortunately one-way tickets. The URL/timestamp would not be used for threading, just for discovery of feeds that you don’t already follow.

I don’t insist on including the timestamp, but having some idea which feed we’re talking about would help a lot.

⤋ Read More
In-reply-to » 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

July 1st. 63 days from now to implement a backward-incompatible change, apparently not open to other ideas like replacing blake with SHA, or discussing implementation challenges for other languages and platforms.
Finally just closing #18, #19 and #20 without starting a proper discussion and ignoring a ‘micro consensus’ feels… not right.

I don’t know what to think rather than letting it rest (May will be busy here) and focus on other stuff in the future.

twt-hash-v2.md#implementation-timeline

⤋ Read More

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

⤋ Read More

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

⤋ Read More
In-reply-to » @sorenpeter you raw feed says otherwise. Also, https://txt.sour.is/conv/wj5bcwq.

@bender@twtxt.net Hehe good sleuthing 🤣 I swear it was an edit ✍️ Haha 😂 yarnd now “sees” both every single time, where-as before it would just obliterate the old Twt, but remain in archive. Now you get to see both 😅 Not sure if that’s a good thing or not, but it certainly makes it much clearer how to write “code logic” for detecting edits and doing something more UX(y) about ‘em 🤔

⤋ Read More

$ bat https://twtxt.net/twt/edgwjcq | jq '.subject'
"(#yarnd)"

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

⤋ Read More

I’m thinking of building a hardened peering protocol for Yarn.social’s yarnd: pods establish cryptographic identities, exchange signed /info and /twt payloads with signature verification, ensuring authenticity, integrity, and spoof-proof identity validation across the distributed network.

⤋ Read More
In-reply-to » @andros maybe create a separate, completely distinct feed for DM? That way, clients do not need to do anything, only those wanted to "talk in private" follow themselves, using their very special dm-only.txt feeds. 😂

by commenting out DMs are you giving up on simplicity? See the Metadata extension holding the data inside comments, as the client doesn’t need to show it inside the timeline.

I don’t think that commenting out DMs as we are doing for metadata is giving up on simplicity (it’s a feature already), and it helps to hide unwanted DMs to clients that will take months to add it’s support to something named… an extension.

For some other extensions in https://twtxt.dev/extensions.html (for example the reply-to hash #abcdfeg or the mention @ < example http://example.org/twtxt.txt >) is not a big deal. The twt is still understandable in plain text.
For DM, it’s only interesting for you if you are the recipient, otherwise you see an scrambled message like 1234567890abcdef=. Even if you see it, you’ll need some decryption to read it. I’ve said before that DMs shouldn’t be in the same section that the timeline as it’s confusing.

So my point stands, and as I’ve said before, we are discussing it as a community, so let’s see what other maintainers add to the convo.

⤋ Read More