@Sumomo@sumomo.neocities.org What client are you using btw? š¤ Does it support threads, and other v2 specs? š¤
If I say companies should at least consider the 3 line CC license before scraping my sites, Iām seen as the unreasonable one.
But when I use an alternative forontend, to read feeds on their sites, without having to make yet another free account, now the same companies and their users scream about some unspecified part of their license being violated, threaten legal action and expect me to care about it.
GitHub thread: https://github.com/zedeus/nitter/issues/1442#issuecomment-5413651441
Real tired of doing these, but hereās another Android developers vs Google update, this time thereās both good and bad news.
The good:
-Users will be able to enable āsideloadingā for all current and future devices, attached to their Google account, rather than having to undergo the tedious 24 hour wait including process, on each device.
-Rather than these changes to āsideloadingā and āadvanced workflowsā being implemented at random different dates, in different countries, weāll all get them come 2027.
The bad:
As GrapheneOS developers recently mentioned āGoogle replaced pushing Git tags for certain source code with obtaining source code via Google Drive after making a request through Google Forms. Itās completely ridiculous and theyāve gradually become very slow at handling requests. Theyāre in clear violation of the GPLv2 now.ā
whole thread: https://grapheneos.social/@GrapheneOS/117057099753905023
@arg@twtpub.com 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 š¤£
but yes, however you cannot currently add it or delete post via the app as I havenāt really built that feature at the moment you technically can do it, but you do run into some challenges with breaking threads if youāve already published something and then go back and edit it so we generally advise not to do that too much if you can help it
da hell? Whatās the root of this thread? š§µ
Posting the review and plan here for posterity as it is related to this thread: https://canvas.mills.io/a/6QVGjzRW
The PR(s) as-is will likely not go ahead Iām afraid. More work to be done, but this is basically all about the āRecoveryā story and how to anchor and notion of an āaccountā without well umm an account š¤£
↳
In-reply-to
»
(#emjrxvngt2mp) not stored on twtd no
ā¤ Read More
sue expand ed on the main thread
↳
In-reply-to
»
@movq @lyse Are you clients remaining compatible with Hash v1 in case older clients are still well not upgraded? š¤
ā¤ Read More
@prologic@twtxt.net No. After the cutoff-date, hashes are expected to be v2. End of story.
(In jenny, a twt can only ever have one thing that can be used for threading.)
Does yarnd still support the old āthreadingā? Letās see.
@movq@www.uninformativ.de ha ha in this case I think Iām OK with a broken thread ha ha
@david@daiwei.me This is another dangling thread:
Trying to fetch "#kyjhiwcxeknm" from Yarn pod https://txt.sour.is ...
Trying to fetch "#kyjhiwcxeknm" from Yarn pod https://twtxt.net ...
Twt could not be found
↳
In-reply-to
»
ā¤ Read More
+00:00 vs Z should be treated as equivalent UTC š¤¦āāļø I'll take a look at the timestamp parsing in Yarnd š§
@lyse@lyse.isobeef.org True. Although I _think) this isnāt a problem and this thread is m00t š
Good morning. Iām seeing so many broken threads. Youāre still investigating this, right?
↳
In-reply-to
»
We someone need to get @kat to update her pod hmmm š¤
ā¤ Read More
Yeah to @david@daiwei.meās point re Editing. Itās only really safe to do so if you are sure that no-one has yet fetched your feed or replied to your Twt. But even then, you have to be quick š¤£ Editing/fixing a Twt inside of an existing thread is āoakyā, as long as it also doesnāt get forked and becomes the root of a new conversation š
@movq@www.uninformativ.de this one:
2026-07-11T17:28:31Z (#fcyeeyd3ii2o) No yet. Letās keep it rolling a little bit longer. I am reply to ā[..] I donāt see any broken threads here. š¤ā. I canāt tag followings while on mobile. <-- THIS BROKE
Was a reply to:
2026-07-11T16:39:22+00:00 (#iqqsqst5vokf) @<david https://daiwei.me/twtxt.txt> Well, I donāt see any broken threads here. š¤
@david@daiwei.me Well, I donāt see any broken threads here. š¤
↳
In-reply-to
»
(#le5zsal5e3lw) @david hmmm, now this one came disconnected. I forked @movq reply, the one stating it was broken.
ā¤ Read More
@bender@twtxt.net No idea. I can only tell you that the correct hash would have been rwzz277nkyju for this line:
[2026-07-11 14:47:17+00:00] [(#5bpwpdcjnhcz) <a href="https://txt.sour.is/external?uri=https://daiwei.me/twtxt.txt">@david<em>@daiwei.me</em></a> (This thread is broken again on my end. Another bug or fix not released yet? š
)]
@bender@twtxt.net Ah, the first twts were from https://raw.githubusercontent.com/Fastidious/fastidious.github.com/master/twtxt.txt, not https://daiwei.me/twtxt.txt. Fetching the GitHub feed completes the thread. š
@david@daiwei.me (This thread is broken again on my end. Another bug or fix not released yet? š )
↳
In-reply-to
»
Okay, wow. Windows NT 4 wasnāt part of my timeline back then, so this is the first time Iām seeing it in action. And this thing came with IE 2, which Iāve also never seen before. (Thatās interesting, because I remember using IE even on Win 3.x, but apparently that was already IE 3?)
ā¤ Read More
As an example, this is a thread @GabesArcade@gabesarcade.comās Arcade@gabesarcade.com and @david@daiwei.me carried all on twtxt.app, no issues: https://twtxt.net/conv/r4uf52ggwseh
↳
In-reply-to
»
Okay, wow. Windows NT 4 wasnāt part of my timeline back then, so this is the first time Iām seeing it in action. And this thing came with IE 2, which Iāve also never seen before. (Thatās interesting, because I remember using IE even on Win 3.x, but apparently that was already IE 3?)
ā¤ Read More
@movq@www.uninformativ.de I figure there is a bug somewhere, but where?
@kiwu@twtxt.net Hanging on by a thread is plenty good enough for many spiders, so it should be sufficient for you, too!!1!
Hmmm the Twtxt App isnāt grouping threads correctly š§
Adding support for forking, forked conversations and navigating back to the root of a thread for the Twtxt App š¤
↳
In-reply-to
»
@GabesArcade Did you by change edit or otherwise delete the Twt you replied to (2nd last in your feed) with the reply/thread id
ā¤ Read More
lleeypvkzbw2? That Twt was never ingested by twtxt.net (and likely the search engine) so umm hmmm threading breaks š¤£
Itās no big deal of course, we are fully aware of the couple of rare(ish) edge cases with the threading model.
@GabesArcade@gabesarcade.com Did you by change edit or otherwise delete the Twt you replied to (2nd last in your feed) with the reply/thread id lleeypvkzbw2? That Twt was never ingested by twtxt.net (and likely the search engine) so umm hmmm threading breaks š¤£
@GabesArcade@gabesarcade.comā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@twtxt.net @bender@twtxt.net incorrectly š
↳
In-reply-to
»
Well well well, the big twtxt-hash version change took place and with just two lines of code I hope, I covered it up in my fiddely little webclient. houseplant programming šŖ“
ā¤ Read More
@arne@uplegger.eu if you see this reply threaded nicely then yes you did! š
↳
In-reply-to
»
I went to check on the fireflies this season. But I didn't see any. Instead lots of moths. At first, I thought it might have been still too light, but it was already dark enough for me to miss and destroy a snail shell. Bummer. Maybe it was too wet tonight. Although, it's probably just another or two weeks until my glowing friends will finally show up.
ā¤ Read More
How truly wonderful! I went out tonight and the first thing I noticed was the temperature drop. It felt actually quite pleasing. What a welcome surprise, I didnāt expect that at all. It was warmer in the forst than between the fields. The tiniest breeze helped to cool off the surroundings I think. Right now, the temperature shows 23Ā°C. Itās supposed to reach 18Ā°C at 5 in the morning before it rapidly shoots through the sky again.
When I left the house I even saw the very end of a nice sunset. A bat was around, too. The several thousand fireflies delivered a fantastic show. Itās such a pity that I cannot show this to you. :-(
There were many frogs or toads around. Luckily, the light tan gravel road made for a good constrast to the darker hopping amphibians. So, I spotted them just in time. No animals were harmed.
The moon was out and lit up the scenery. I was perfectly chasing my own shadow for several hundred meters on a forest road. I had the moon right in my back. That moon light shadow felt magical. <3
It must have set a new record on picking up spider webs along the way. The threads around arms and legs always feel quite yucky. People were blasting music somewhere in town. You could here that noise in the entire forest. I found that rather annoying. All street lamps are operational again, so I got already blinded right at the entrance to the town. But other than that, this was a very nice evening stroll. Totally recommended. Already looking forward to tomorrow. :-)
Ask HN: Are you still using your Vision Pro?
Almost two years ago there was a thread on this (https://news.ycombinator.com/item?id=40872102). Iām curious now that more time has passed what people think?
Comments URL: https://news.ycombinator.com/item?id=48465702
Points: 14
# Comments: 5 ā Read more
Please donāt spam people looking for employment. Itās just cruel
Earlier I posted in a āWho wants to be hired?ā thread, looking for a place where I could apply my experience in hospitality, food tech and automation.
A couple hours later I received an email:
āHi Ilia,
I saw your comment on the June Whoās Hiring thread. I build production-ready TypeScript and Python systems that integrate LLMs into real workflows, with particular focus on RAG, agent orchestration, and clear blah-blah-blahā
Come on.
I am a forced immigra ā¦ ā Read more
Nice work! Threading + mentions is where it gets fun š Ping me if anything in the spec is unclear š
@itsericwoodward@itsericwoodward.com Excited to see twtxt tooling in the Node ecosystem! Any plans to implement the Twtxt v2 extensions? Things like Twt Hash + Subject (proper threading), Multiline, etc. ā all documented at https://twtxt.dev š
↳
In-reply-to
»
@lyse @tftp Someone has pointed out that thereās OpenRsync:
ā¤ Read More
@movq@www.uninformativ.de I came across that in some of these threads, too. I should probably give OpenRsync a shot.
↳
In-reply-to
»
@movq I'm very curious...
ā¤ Read More
@movq@www.uninformativ.de Iām kind of flag you bring thi sup, because you simply canāt. You wouldnāt even be able to in an atypical neural network either (which is what ehse things are anyway). The problem here really isnāt the so-called āAIā (I wish weād stop calling it AI), but the flawed usage(s) thereof. I believe I even stated earlier in this thread that sometimes it may not do what you expect, itās āprobabilisticā not ādeterministicā ā those pushing for greater use need to understand this, those not happy with the āpushā, should educate the ignorant here (especailly managers pushing for weak, insecure and bad uses).
↳
In-reply-to
»
@lyse (Do you want to be linked on that page? Do you want your name to be there at all? š¤)
ā¤ Read More
@movq@www.uninformativ.de I really like your style of writing, btw. Itās much calmer and less aggressive then mine. :-) When I turned my bullet points into paragraphs, I got a bit mad in the process.
Sure, feel free to include anything you want. Regarding citing, this is where twtxt falls short in my opinion. Especially with feed rotation, classic links die quickly. Message hashes only help so much. Nobody outside the twtxt universe knows how to deal with them. So, not perfect for inclusion on a web page. Linking to a thread or message on some yarnd instance might be the more user-friendly option. But the disadvantage is that itās ājustā a mirror, not the primary or original source. In all reality, this could be considered splitting hairs, though.
I should have probably written a proper article. That would have given me time to review the result more carefully, too. ;-) Perhaps thatās something for the future. But honestly, Iām not sure if I really want to waste my time and energy on that subject. So many other fun or useless things come to mind right away that I could do instead. 8-)
So, yeah, do whatever feels best to you. I donāt mind being cited or linked, but I also donāt mind not to be cited or not to be linked to. :-D Not a helpful answer, I know. Sorry. ;-) But anyway, thanks for asking, mate! I do appreciate it.
To finish my thought, linking to my frontpage is probably also useless, since I deliberatly do not have a table of contents there. In fact, my entire frontpage is rather silly.
@rdlmda@rdlmda.me You also minimally need to be calculate message hases at some point, if you want to form threads that is (copying existing ones is easy) š
↳
In-reply-to
»
Use more WebP, I guess.
ā¤ Read More
Searching the web a bit brings up lots of threads where people hate WebP. The problem being that browsers support WebP but other programs tend to be problematic ā¦ ? š¤
↳
In-reply-to
»
We'll all my posts are making it to the "Fediverse" https://bridge.twtxt.net/users/c350a5e5fb9d9457
ā¤ Read More
Need to fix:
- threads
-media and links
I think i may have fixed threading too but canāt easily test now as iāve left for my
holiday and donāt really use Mastodon š
↳
In-reply-to
»
Hey @prologic š
ā¤ Read More
@therealprologic@bridge.twtxt.net Sweet! Mentions are fixed! š Now just have to fix threading!
↳
In-reply-to
»
@c350a5e5fb9d9457 Does this mean we'res starting to work, this whole Twtxt <-> ActivityPub bridge thingy? š¤
ā¤ Read More
@therealprologic@bridge.twtxt.net Okay so the mention translation is. busted and umm the threading is busted. But other than that, so far so good š
↳
In-reply-to
»
There are no really good GUI toolkits for Linux, are there?
ā¤ Read More
FTR, I see one (two) issues with PyQt6, sadly:
- The PyQt6 docs appear to be mostly auto-generated from the C++ docs. And they contain many errors or broken examples (due to the auto-conversion). I found this relatively unpleasent to work with.
- (Until Python finally gets rid of the Global Interpreter Lock properly, itās not really suited for GUI programs anyway ā in my opinion. You canāt offload anything to a second thread, because the whole program is still single-threaded. This would have made my fractal rendering program impossible, for example.)
↳
In-reply-to
»
Hello World! Testing 1 2 3
ā¤ Read More
@therealprologic@bridge.twtxt.net It works! š¤£ Now Iām quite sure we havenāt got threads working yet š¤
↳
In-reply-to
»
Hmmm all these
ā¤ Read More
tilde.club feeds have no # nick and is messing with yarnd's behavior š
@prologic@twtxt.net And none of them use Yarn-style threading. I donāt think theyāre aware of us, theyāre probably using plain twtxt. Other than one hit by @threatcat@tilde.club a few days ago, Iāve seen no traffic from them. š¤
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).
Python 3.14.0 released
Version\āØ3.14.0 of the Python language has been released. There are a lot of
changes this time around, including official support for free threading, template string literals, and much more; see
the announcement for details. ā Read more
Hello again everyone! A little update on my twtxt client.
I think itās finally shaping a bit better now, butā¦ āļø
As Iām trying to put all the parts together, I decided to build multiple parallel UIs, to ensure I donāt accidentally create a structure that is more rigid than planned.
I already decided on a UI that I would want to use for myself, it would be inspired by moshidon, misskey and some other āsocial feedsā mock-ups I found on dribbble.
I also plan on building a raw HTML version (for anyone wanting to do a full DIY client).
I would love to get any suggestions of what you would like to see (and possibly use) as a client, by sharing a link, app/website name or even a sketch made by you on paper.
I think Iāll pick a third and maybe a fourth design to build together with the two already mentioned.
For reference, the screens I think of providing are (some might be optional or conditionally/manually hidable):
- Global / personal timeline screen
- Profile screen (with timeline)
- Thread screen
- Notifications screen or popup (both valid)
- DM list & chat screens (still planning, might come later)
- Settings screen (itāll probably be a hard coded form, but better mention it)
- Publish / edit post screen or popup (still analysing some use cases, as some āenginesā might not have direct publishing support)
I also plan on adding two optional metadata fields:
display_name: To show a human readable alternative for a nick, it fallback tonickif not defined
banner: Using the same format asavatarbut the image expected is wider, inspired by other socials around
I also plan on supporting any metadata provided, including a dynamically parsable regex rule format for those extra fields, this should allow anyone to build new clients that donāt limit themselves to just the social aspect of twtxt, hoping to see unique ways of using twtxt! š¤
↳
In-reply-to
»
is the first
ā¤ Read More
url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they're not at least proper urls? do you just tolerate it if they're impersonating someone else's feed, or pointing to something that isn't even a feed at all?
@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).
↳
In-reply-to
»
is the first
ā¤ Read More
url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they're not at least proper urls? do you just tolerate it if they're impersonating someone else's feed, or pointing to something that isn't even a feed at all?
@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.
↳
In-reply-to
»
I would personally rather see something like this:
ā¤ Read More
@alexonit@twtxt.alessandrocutolo.it Well we have to really use the same spec or threading doesnāt really work in a truly decentralized manner š
↳
In-reply-to
»
@bender Really? š¤
ā¤ Read More
@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).
↳
In-reply-to
»
I would personally rather see something like this:
ā¤ Read More
@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.
↳
In-reply-to
»
TNO Threading (draft):
Each origin feed numbers new threads
ā¤ Read More
Each origin feed numbers new threads
(tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
@prologic@twtxt.net Thatās a completely flat threading model (you canāt reply to replies). Is that intentional?
↳
In-reply-to
»
TNO Threading (draft):
Each origin feed numbers new threads
ā¤ Read More
Each origin feed numbers new threads
(tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
This is possibly the only other threading model I can come up with for Twtxt that I think I can get behind.
↳
In-reply-to
»
TNO Threading (draft):
Each origin feed numbers new threads
ā¤ Read More
Each origin feed numbers new threads
(tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
Example:
Alice starts thread href=āhttps://txt.sour.is/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)(implicitofeed=self).
- Replies:
(tno:N) (ofeed:<url>).
- Clients: increment
tnolocally for new threads, copy tags on reply.
- Subjects optional, not required.
ā¦
↳
In-reply-to
»
Here is just a small list of thingsā¢ that I'm aware will break, some quite badly, others in minor ways:
ā¤ Read More
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.
↳
In-reply-to
»
Here is just a small list of thingsā¢ that I'm aware will break, some quite badly, others in minor ways:
ā¤ Read More
@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.
↳
In-reply-to
»
Here is just a small list of thingsā¢ that I'm aware will break, some quite badly, others in minor ways:
ā¤ Read More
@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:
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.
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.
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?
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.
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. :-)
↳
In-reply-to
»
@zvava @lyse I also think a location based reference might be better.
ā¤ Read More
Here is just a small list of thingsā¢ that Iām aware will break, some quite badly, others in minor ways:
- 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.
- Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several āparentsā and split the thread.
- 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.
- Offline/cached reading: without the original URL being reachable, readers canāt resolve anchors; with hashes they can match against local caches/archives.
- 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.
↳
In-reply-to
»
@zvava @lyse I also think a location based reference might be better.
ā¤ Read More
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.
↳
In-reply-to
»
@lyse i dont mind if the hash is not backward compatible but im not sure if this is the right way to proceed because the added complexity dealing with two hash versions isnt justified
ā¤ Read More
@zvava@twtxt.net @lyse@lyse.isobeef.org I also think a location based reference might be better.
A thread is a single post of a single feed as a root, but the hash has the drawback of not referencing the source, in a distributed network like twtxt it might leave some people out of the whole conversation.
I suggest a simpler format, something like: (#<TIMESTAMP URL>)
This solves three issues:
- Easier referencing: no need to generate a hash, just copy the timestamp and url, itās also simpler to implement in a client without the rish of collisions when putting things together
- Fetchable source: you can find the source within the reference and construct the thread from there
- Allow editing: If a post is modified the hash becomes invalid since it depends on
[ timestamp, url, content ]