Ikea’s Big Smart Home Push Arrives With 21 New Matter Devices
The Scandinavian furniture giant has unveiled 21 new ultra-affordable Matter-over-Thread smart home devices across three launch segments: lighting, sensors, and control. With prices starting at just a few dollars, Ikea is pushing hard to replace its old Zigbee lineup and become a serious player in the Matter ecosystem. Forbes reports: Back to the 21 n … ⌘ Read more

GTK2 about to be removed from the official Arch repos: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/2BDHYLEFSYQBDTMUOZT5J6AFTA5M3FO6/

It’ll probably all be dropped to the AUR, so I can build this myself, because I still have some stuff that depends on it (and will never receive further updates).

@zvava@twtxt.net My clients trusts the first url field it finds. If there is none, it uses the URL that I’m using for fetching the feed.

No validation, no logging.

In practice, I’ve not seen issues with people messing with this field. (What I do see, of course, is broken threads when people do legitimate edits that change the hash.)

I don’t see a way how anyone can impersonate anybody else this way. 🤔 Sure, you could use my URL in your url field, but then what? You will still show up as zvava in my client or, if you also change your nick field, as movq (zvava).

@zvava@twtxt.net Yes, the specification defines the first url to be used for hashing. No matter if it points to a different feed or whatever. Just unsubscribe from malicious feeds and you’re done.

Since the first url is used for hashing, it must never change. Otherwise, it will break threading, as you already noticed. If your feed moves and you wanna keep the old messages in the same new feed, you still have to point to the old url location and keep that forever. But you can add more urls. As I said several times in the past, in hindsight, using the first url was a big mistake. It would have been much better, if the last encountered url were used for hashing onwards. This way, feed moves would be relatively straightforward. However, that ship has sailed. Luckily, feeds typically don’t relocate.

@alexonit@twtxt.alessandrocutolo.it Well we have to really use the same spec or threading doesn’t really work in a truly decentralized manner 😉

@zvava@twtxt.net Going to have to hard disagree here I’m sorry. a) no-one reads the raw/plain twtxt.txt files, the only time you do is to debug something, or have a stick beak at the comments which most clients will strip out and ignore and b) I’m sorry you’ve completely lost me! I’m old enough to pre-date before Linux became popular, so I’m not sure what UNIX principles you think are being broken or violated by having a Twt Subject (Subject) whose contents is a cryptographic content-addressable hash of the “thing”™ you’re replying to and forming a chain of other replies (a thread).

I’m sorry, but the simplest thing to do is to make the smallest number of changes to the Spec as possible and all agree on a “Magic Date” for which our clients use the modified function(s).

@alexonit@twtxt.alessandrocutolo.it My problem is I don’t see a world where we don’t employ some form of cryptography to use as keys for threads in databases and other such things honestly. I’m not going to use url#timestamp as keys.

@prologic@twtxt.net That’s a completely flat threading model (you can’t reply to replies). Is that intentional?

This is possibly the only other threading model I can come up with for Twtxt that I think I can get behind.

Example:

Alice starts thread href=”https://we.loveprivacy.club/search?q=%2342:”>#42:**

2025-09-25T12:00:00Z (tno:42) Launching storage design review.

Bob replies:

2025-09-25T12:05:00Z (tno:42) (ofeed:https://alice.example/twtxt.txt
) I think compaction stalls under load.

Carol replies to Bob:

2025-09-25T12:08:00Z (tno:42) (ofeed:https://alice.example/twtxt.txt
) Token bucket sounds good.

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.
  

…

I was trying to say (badly):

That’s kind of my position on this. If we are going to make significant changes in the threading model, let’s keep content based addressing, but also improve the user experience. Answering your question, yes I think we can do some combination of both.

@alexonit@twtxt.alessandrocutolo.it Yhays kind of love you!! Stance and position on this. If we are going to make chicken changes in the threading model, let’s keep content based addressing, but also improve the use of experience. So in fact, in order to answer your question, I think yes, we can do some kind of combination of both.

@prologic@twtxt.net I know we won’t ever convince each other of the other’s favorite addressing scheme. :-D But I wanna address (haha) your concerns:

1. I don’t see any difference between the two schemes regarding link rot and migration. If the URL changes, both approaches are equally terrible as the feed URL is part of the hashed value and reference of some sort in the location-based scheme. It doesn’t matter.

2. The same is true for duplication and forks. Even today, the “cannonical URL” has to be chosen to build the hash. That’s exactly the same with location-based addressing. Why would a mirror only duplicate stuff with location- but not content-based addressing? I really fail to see that. Also, who is using mirrors or relays anyway? I don’t know of any such software to be honest.

3. If there is a spam feed, I just unfollow it. Done. Not a concern for me at all. Not the slightest bit. And the byte verification is THE source of all broken threads when the conversation start is edited. Yes, this can be viewed as a feature, but how many times was it actually a feature and not more behaving as an anti-feature in terms of user experience?

4. I don’t get your argument. If the feed in question is offline, one can simply look in local caches and see if there is a message at that particular time, just like looking up a hash. Where’s the difference? Except that the lookup key is longer or compound or whatever depending on the cache format.

5. Even a new hashing algorithm requires work on clients etc. It’s not that you get some backwards-compatibility for free. It just cannot be backwards-compatible in my opinion, no matter which approach we take. That’s why I believe some magic time for the switch causes the least amount of trouble. You leave the old world untouched and working.

If these are general concerns, I’m completely with you. But I don’t think that they only apply to location-based addressing. That’s how I interpreted your message. I could be wrong. Happy to read your explanations. :-)

Here is just a small list of things™ that I’m aware will break, some quite badly, others in minor ways:

1. Link rot & migrations: domain changes, path reshuffles, CDN/mirror use, or moving from txt → jsonfeed will orphan replies unless every reader implements perfect 301/410 history, which they won’t.
   
2. Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several “parents” and split the thread.
   
3. Verification & spam-resistance: content addressing lets you dedupe and verify you’re pointing at exactly the post you meant (hash matches bytes). Location anchors can be replayed or spoofed more easily unless you add signing and canonicalization.
   
4. Offline/cached reading: without the original URL being reachable, readers can’t resolve anchors; with hashes they can match against local caches/archives.
   
5. Ecosystem churn: all existing clients, archives, and tools that assume content-derived IDs need migrations, mapping layers, and fallback logic. Expect long-lived threads to fracture across implementations.

We’ve been discussing the idea of changing the threading model from Content-based Addressing to Location-based addressing for years now. The problem is quite complex, but I feel I have to keep reminding y’all of the potential perils of changing this and the pros/cons of each model:

With content-addressed threading, a reply points at something that’s intrinsically identified (hash of author/feed URI + timestamp + content). That ID never changes as long as the content doesn’t. Switching to location-based anchors makes the reply target extrinsic—it now depends on where the post currently lives. In a pull-based, decentralised network, locations drift. The moment they do, thread identity fragments.

@zvava@twtxt.net It is just completely impossible to make v2 backwards-compatible with v1.

Well, breaking threads on edits is considered a feature by some people. I reckon the only approach to reasonably deal with that property is to carefully review messages before publishing them, thus delaying feed updates. Any typos etc., that have been discovered afterwards, are just left alone. That’s what I and some others do. I only risk editing if the feed has been published very few seconds earlier. More than 20 seconds and I just ignore it. Works alright for the most part.

@movq@www.uninformativ.de Yeah, we’ve seen how this plays out in practice 🤣 @dce@hashnix.club My advice, do what @movq@www.uninformativ.de has hinted at and don’t change the 1st # url = field in your feed. I’m not sure if you had already, but the first url field is kind of important in your feed as it is used as the “Hashing URI” for threading.

@lyse@lyse.isobeef.org Multi-Threading. Is. Hard. 🤯 And yes, that blog is great. 👌

https://threadreaderapp.com/thread/1935344122103308748.html Interesting article on how ChatGPT is rotting your brain 🤣

One of the nicest things about Go is the language itself, comparing Go to other popular languages in terms of the complexity to learn to be proficient in:

• Go: 25 keywords (Stack Overflow); CSP-style concurrency (goroutines & channels)
  
• Python 2: 30 keywords (TutorialsPoint); GIL-bound threads & multiprocessing (Wikipedia)
  
• Python 3: 35 keywords (Initial Commit); GIL-bound threads, asyncio & multiprocessing (Wikipedia, DEV Community)
  
• Java: 50 keywords (Stack Overflow); threads + java.util.concurrent (Wikipedia)
  
• C++: 82 keywords (Stack Overflow); std::thread, atomics & futures (en.cppreference.com)
  
• JavaScript: 38 keywords (Stack Overflow); single-threaded event loop & async/await, Web Workers (Wikipedia)
  
• Ruby: 42 keywords (Stack Overflow); GIL-bound threads (MRI), fibers & processes (Wikipedia)
  

@andros@twtxt.andros.dev @eapl.me@eapl.me Still lots of bugs in my client. 🥴 I’ll try to fix it next week.

And yes, using the same timestamp twice will very likely break threads.

@andros@twtxt.andros.dev I set up a test feed here:

https://www.uninformativ.de/texudus.txt

I made some preliminary adjustments to my client so that it can work with the different threading model. (And I totally get the concerns, this can be quite a bit of work. Especially in a large code base like Yarn.)

@bender@twtxt.net Mainly the bsd.cafe ones. I like how the minimalist single column profiles look. Image embeds are full width and reading through threads feels nice (as in it doesn’t feel like pealing layers upon layers of a fresh onion).

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.

@eapl.me@eapl.me I honestly believe you are overreacting here a little bit 🤣 I completely emphasize with you, it can be pretty tough to feel part of a community at times and run a project with a kind of “democracy” or “vote by committee”. But one thing that life has taught me about open source projects and especially decentralised ecosystems is that this doesn’t really work.

It isn’t that I’ve not considered all the other options on the table (which can still be), it’s just that I’ve made a decision as the project lead that largely helped trigger a rebirth of the use of Twtxt back in July 1 2020. There are good reasons not to change the threading model right now, as the changes being proposed are quite disruptive and don’t consider all the possible things that could go wrong.

@bmallred@staystrong.run Hehe, @bender@twtxt.net is gonna be upset with you for “making up a thread/subject” 🤣

@bender@twtxt.net Nah it’s there but it’s a reply to a thread that isn’t found here hmmm 🤔

@abucci@anthony.buc.ci Haha you’ll have to forgive me, this thread is over a week old now and I’m a bit lost now 🤣 even though I can now see the entire thread, what are we saying was messed up and is garbled? 🤔

@bender@twtxt.net Hehe, thanks for fixing this (was) broken thread 🧵 Haha 🤣

Am I the only one that’s confused by the discussions, and then the voting we had on the whole threading model? 🤔 I’m not even sure what I voted for, but I know it wasn’t the one that won haha 🤣 (which I’m still very much against for based on an intuition, experience and lots of code writing lately).

@prologic@twtxt.net Shit like what? References/threads? 😅

Timeline of Evolution of Twtxt/Yarn.social:

• 2016 – Twtxt created by John Downey: plain text + HTTP = minimalist microblogging
  
• 2017–2019 – Community builds CLI tools, but adoption remains niche
  
• 2020 – Yarn.social launched by @prologic@twtxt.net with federation, threading, UI
  
• 2021–2023 – Pods sync, user mentions, blocking, search, and media support added
  
• 2024+ – Yarn.social becomes the reference Twtxt platform, with active federated pods

I asked ChatGPT what it knows about Twtxt 😂 And surprisingly it’s rather accurate:

Twtxt is a minimalist, decentralized microblogging format introduced by John Downey in 2016. It uses plain text files served over HTTP—no accounts, databases, or APIs.
In 2020, James Mills (@prologic@twtxt.net) launched Yarn.social, an extended, federated implementation with user discovery, threads, mentions, and a full web UI.
Both share the same .twtxt.txt format but differ in complexity and social features.

@kat@yarn.girlonthemoon.xyz It’s more like a cache, it stores things like “timestamp of the most recent twt we’ve seen per feed” or “last modification date” (to be used with HTTP’s if-modified-since header). You can nuke these files at any time, it might just result in more traffic (e.g., always getting a full response instead of just “HTTP 304 nope, didn’t change”).

@quark@ferengi.one Yes, I often write a couple of twts, don’t publish them, then sometimes notice a mistake and want to edit it. You’re right, as soon as stuff is published, threads are going to break/fork by edits.

@quark@ferengi.one No editing old Twts that are the root of a thread with replies in the ecosystem. Just results in a fork. Unless the client has an implementation that does not store Twts keyed by Hash.

@david@collantes.us Yeah, we’ve been debugging that a bit yesterday. Looks like the wrong input (sometimes) gets fed to the hash function → broken threads.

@david@collantes.us Ah, yes, the hardware might not. As I just said in the other thread: No problem, you can keep the same installation. I did so many times on my PC/laptop at work.

@prologic@twtxt.net The threads’ broken for me, I can’t find znf6csa. 🤔

@bender@twtxt.net Yeah, as you mentioned in the other thread, @andros@twtxt.andros.dev’s hashes appear to be not quite right. 🤔

@andros@twtxt.andros.dev hmmm… pretty strange, isn’t it? replaying to threads worked perfectly, I’ve only had that problem trying to replay to a twt that was part of a thread.

As an example, this one is a Fork-Replay from Jenny. My next twt will be a replay to this exact twt but from twtxt-el as a test.
Then I’will file an issue if it doesn’t behave the way it’s supposed to. Cheers!

@eapl.me@eapl.me I like this idea. Another option would be to show a limited number of posts, with an option to see the omitted ones by user. Either way, I wonder how well that works with threading.

@lyse@lyse.isobeef.org The one in question is more like the javascript version for unwrapping errors when accessing methods.

 const value = some?.deeply?.nested?.object?.value

but for handling errors returned by methods. So if you wanted to chain a bunch of function calls together and if any error return immediately. It would be something like this:

b:= SomeAPIWithErrorsInAllCalls()
b.DoThing1() ?
b.DoThing2() ?

// Though its not in the threads I assume one could do like this to chain.
b.Chain1()?.Chain2()?.End()?

I am however infavor of having a sort of ternary ? in go.

PS. @prologic@twtxt.net for some reason this is eating my response without throwing an error :( I assume it has something to do with the CSRF. Can i not have multiple tabs open with yarn?

@movq, @prologic@twtxt.net when navigating to a Yarn. If the head twt is missing then the whole thread is not accessible. It only returns an error. so i have no way to view any of the replies within the thread other than the end twt.

I like the cleaness and indiewebness of using just domains for handles/shorthands similar to blusky, but the situations with more users on the same domain and that people in the fediverse (threads too?) are already familiar with the syntax speaks for webfinger. And since we already got support for webfinger in both yarnd and timeline it makes sense to stick with it.

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

1. If yarn has one use that. (Maybe do collision check?)
   
2. Make hash of twt raw no truncation.
   
3. Check local cache for shortest without collision
   
   • in SQL: select len(subject) where head_full_hash like subject || '%'
     

Threading:

1. Get full hash of head twt
   
2. Search for twts
   
   • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp
     

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.

I mean sure if i want to run it over on my tooth brush why not use something that is accessible everywhere like md5? crc32? It was chosen a long while back and the only benefit in changing now is “i cant find an implementation for x” when the down side is it breaks all existing threads. so…

@prologic@twtxt.net YES James, it should be up to the client to deal with changes like edits and deletions. And putting this load on the clients, location-addressing with make this a lot easier since what is says it: Look in this file at this timestamp, did anything change or went missing? (And then threading will not break;)

@bender@twtxt.net I am also in camp no edit signals. deletes only breaks the head of a thread. all the replies are unaffected.

#fzf is the new emacs: a tool with a simple purpose that has evolved to include an #email client. https://sr.ht/~rakoo/omail/

I’m being a little silly, of course. fzf doesn’t actually check your email, but it appears to be basically the whole user interface for that mail program, with #mblaze wrangling the emails.

I’ve been thinking about how I handle my email, and am tempted to make something similar. (When I originally saw this linked the author was presenting it as an example tweaked to their own needs, encouraging people to make their own.)

This approach could surely also be combined with #jenny, taking the place of (neo)mutt. For example mblaze’s mthread tool presents a threaded discussion with indentation.