Searching We.Love.Privacy.Club

Twts matching #Twt
Sort by: Newest, Oldest, Most Relevant
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
In-reply-to » (#22qxisq) @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 » (#22qxisq) @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
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 » 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://we.loveprivacy.club/search?q=%23123467">#123467</a>) hello foo bar

you would have

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

or maybe even:

(<a href="https://we.loveprivacy.club/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

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

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

@andros@twtxt.andros.dev Haha 🤣 We’ve explored this idea in the past and we decided that it’s actually a good idea to have an “append-only” feed for various reasons. We’ve also explored the idea of using Range requests, but opted instead to just archive/rotate our feeds periodically 😅 There really isn’t much point in having a feed in reverse chronological order, except (maybe?) so a human read view the new twts at the top of the file?! 🤣

⤋ Read More
In-reply-to » All these remind me of the "blog" ability once existed in Yarnd. I hate to be the party pooper, but little to non interest from me. LOL. I am up to increase the length of a twtxt, though. It is rather limiting right now.

See:

<textarea id="text" name="text" placeholder="Hi! 👋 Don't forget to post a Twt today!" rows="4" maxlength="576" required="true" aria-required="true"></textarea>

So, 576?

⤋ Read More

**(#tdyfazq) Holy hell?! When I post this:

@<kate https://yarn.girlonthemoon.xyz/user/kat/twtxt.txt> Glad you think so! 👌 My goal with Yar ...**
Holy hell?! When I post this:

@kate@yarn.girlonthemoon.xyz Glad you think so! 👌 My goal with Yarn.social has always been to provide the best (best that I can anyway!) truly decentralised (slow) social experience that uses the Twtxt format under the hood 😅

”`

Something is swallowing it. ⌘ Read more”`

⤋ Read More