One of the biggest gripes of the community with the way the threading model currently works with Twtxt v1.2 (https://twtxt.dev) is this notion of:

What is this hash?
What does it refer to?

Idea: Why can’t we all agree to implement a simple URI scheme where we host our Twtxt feeds?

That is, if you host your feed at https://example.com/twtxt.txt – Why can’t or could you not also host various JSON files (let’s agree on the spec of course) at https://example.com/twt/<hash> ? 🤔

That way we solve this problem in a truly decentralised way, rather than every relying on yarnd pods alone.

@prologic@twtxt.net We can’t agree on this idea because that makes things even more complicated than it already is today. The beauty of twtxt is, you put one file on your server, done. One. Not five million. Granted, there might be archive feeds, so it might be already a bit more, but still faaaaaaar less than one file per message.

Also, you would need to host not your own hash files, but everybody else’s as well you follow. Otherwise, what is that supposed to achieve? If people are already following my feed, they know what hashes I have, so this is to no use of them (unless they want to look up a message from an archive feed and don’t process them). But the far more common scenario is that an unknown hash originates from a feed that they have not subscribed to.

Additionally, yarnd’s URL schema would then also break, because https://twtxt.net/twt/<hash> now becomes https://twtxt.net/user/prologic/<hash>, https://twtxt.net/user/bender/<hash> and so on. To me, that looks like you would only get hashes if they belonged to this particular user. Of course, you could define rules that if there is a /user/ part in the path, then use a different URL, but this complicates things even more.

Sorry, I don’t like that idea.

@lyse@lyse.isobeef.org Sorry I didn’t mean to upset you or anyone here in the community. I am/was merely trying to solve what I perceive to be a problem and an ask in the community:

How do I know what a hash refers to?

I believe the reason for this stems from a curiosity of the user of whether they might find that thread interesting or whether there are new interested feeds to follow?

Although my idea increases complexity slightly (introducing a new concept) I don’t think it’s particular hard to understand, reason about or implement (complicated). One could even even make the implementation quite simple in fact.

Either way, the idea of a service (cantralised) or participating clients/registries (distributed) providing reverse hash lookups doesn’t sound too bad really.

What do you propose to solve the above problem? 🤔

@doesnm@doesnm.p.psf.lt Actually that’s a fantastic idea 🙌