# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 60515
# self = https://watcher.sour.is?uri=https://twtxt.net/user/prologic/twtxt.txt&offset=56591
# next = https://watcher.sour.is?uri=https://twtxt.net/user/prologic/twtxt.txt&offset=56691
# prev = https://watcher.sour.is?uri=https://twtxt.net/user/prologic/twtxt.txt&offset=56491
I _think_ Email Message-Id(s) only ever worked because typically you are exchanging emails with recipients you know and vice versa. It's much easier to cope with the problems above, because you just ensure your client preserves the Message-Id. Email is a federated system, but by no means is it "decentralised". You still have to send your email somewhere, not just post it on a website on your own server like Twtxt πŸ˜…

There are some subtitles differences like this that makes Message/Thread Id(s) not really that suitable IMO.
I _think_ Email Message-Id(s) only ever worked because typically you are exchanging emails with recipients you know and vice versa. It's much easier to cope with the problems above, because you just ensure your client preserves the Message-Id. Email is a federated system, but by no means is it "decentralised". You still have to send your email somewhere, not just post it on a website on your own server like Twtxt πŸ˜…

There are some subtitles differences like this that makes Message/Thread Id(s) not really that suitable IMO.
@bender The problem with the approach Email clients do things is;

- How do you come up with the message/thread id in the first place? I'm pretty sure most clients just use a UUID.
- How do you know what you're replying to if you don't see the message/thread id in the first place?
- How do two different users that don't know each other, but follow the same feed (say /.) make two independent responses forming a thread? What message/thread id do they use? (see above)
@bender The problem with the approach Email clients do things is;

- How do you come up with the message/thread id in the first place? I'm pretty sure most clients just use a UUID.
- How do you know what you're replying to if you don't see the message/thread id in the first place?
- How do two different users that don't know each other, but follow the same feed (say /.) make two independent responses forming a thread? What message/thread id do they use? (see above)
@bender Sorry, trust was the wrong word. Trust as in, you do not have to check with anything or anyone that the hash is valid. You can verify the hash is valid by recomputing the hash from the content of what it points to, etc.
@bender Sorry, trust was the wrong word. Trust as in, you do not have to check with anything or anyone that the hash is valid. You can verify the hash is valid by recomputing the hash from the content of what it points to, etc.
@falsifian Yes;

> I don’t think twtxt hashes are long enough to prevent spoofing.

The current spec needs to be updated to expand the hash length to 11 characters to avoid hash collisions (_which will happen at some point with 7, if not already_).

The issue isn't dealing with "spoofing", it's about solving how clients in a decentralised model agree on the threading model and identity of a thread. Message ID(s) suffer from the fact that as @movq points out, clients have to "obey" this unwritten rule, but they're otherwise just arbitrary. Whereas Twt Hashes (_I didn't come up with the idea originally, some smart fellow in cryptography did_) are content addressable, meaning that clients don't have to agree on anything, they can trust that the hash is a cryptographic representing of the thread they're replying to, no matter what.
@falsifian Yes;

> I don’t think twtxt hashes are long enough to prevent spoofing.

The current spec needs to be updated to expand the hash length to 11 characters to avoid hash collisions (_which will happen at some point with 7, if not already_).

The issue isn't dealing with "spoofing", it's about solving how clients in a decentralised model agree on the threading model and identity of a thread. Message ID(s) suffer from the fact that as @movq points out, clients have to "obey" this unwritten rule, but they're otherwise just arbitrary. Whereas Twt Hashes (_I didn't come up with the idea originally, some smart fellow in cryptography did_) are content addressable, meaning that clients don't have to agree on anything, they can trust that the hash is a cryptographic representing of the thread they're replying to, no matter what.
@falsifian I like this idea actually for edits.
@falsifian I like this idea actually for edits.
@movq Care to share your thoughts here?

> I don’t know what happened behind the scenes that killed off twtxt (I have a few guesses, though), but the sad truth is that it’s gone.
@movq Care to share your thoughts here?

> I don’t know what happened behind the scenes that killed off twtxt (I have a few guesses, though), but the sad truth is that it’s gone.
Agreed
Agreed
@bender A Fred changed its url metadata field 🀣
@bender A Fred changed its url metadata field 🀣
After unfollowing and refollowing on the new feed URL, I'm now 100% certain this is what happened for @cuaxolotl 🀣 The _real_ problem is really this:

> How do we identify a feed?

It cannot be the URL, because the author _could_ change where they serve it from. This was as "good" as we could get it, but time and time again this has proven to be problematic for, well, a few folks that change their mind, which frankly should be allowed πŸ˜…
After unfollowing and refollowing on the new feed URL, I'm now 100% certain this is what happened for @cuaxolotl 🀣 The _real_ problem is really this:

> How do we identify a feed?

It cannot be the URL, because the author _could_ change where they serve it from. This was as "good" as we could get it, but time and time again this has proven to be problematic for, well, a few folks that change their mind, which frankly should be allowed πŸ˜…
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it _should_ put the hash of the previous Twt. Something like:


2024-09-05T13:37:40Z   (edit:mp6ox4a) Hello world!
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it _should_ put the hash of the previous Twt. Something like:


2024-09-05T13:37:40Z   (edit:mp6ox4a) Hello world!
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it _should_ put the hash of the previous Twt. Something like:


2024-09-05T13:37:40+00:00   (edit:mp6ox4a) Hello world!
For supporting edits, I was thinking more along the lines of: If a client edits a Twt already published, it _should_ put the hash of the previous Twt. Something like:


2024-09-05T13:37:40+00:00   (edit:mp6ox4a) Hello world!
To be honest, I don't really see "editing" as a problem. I see that as a natural behavior of "forking" in the first place, that just forms a. new sub-tree. What's _really_ problematic here is when a feed author changes the "identity" of their feed and changes the # url = metadata field, which is what I _believe_ @cuaxolotl has just done, though I'm not 100% certain, I'm like 98% sure haha 😝
To be honest, I don't really see "editing" as a problem. I see that as a natural behavior of "forking" in the first place, that just forms a. new sub-tree. What's _really_ problematic here is when a feed author changes the "identity" of their feed and changes the # url = metadata field, which is what I _believe_ @cuaxolotl has just done, though I'm not 100% certain, I'm like 98% sure haha 😝
@lyse Did you check your pocket? 🀣
@lyse Did you check your pocket? 🀣
@movq Sorry but what's a partial hash exactly? πŸ€”
@movq Sorry but what's a partial hash exactly? πŸ€”
@cuaxolotl Did you recently change the url metdata key of your feed?


# url = https://sunshinegardens.org/~xj9/twtxt/tw.txt


Was this at one point # url = https://sunshinegardens.org/users/xj9/twtxt/tw.txt?
@cuaxolotl Did you recently change the url metdata key of your feed?


# url = https://sunshinegardens.org/~xj9/twtxt/tw.txt


Was this at one point # url = https://sunshinegardens.org/users/xj9/twtxt/tw.txt?
@lyse Please for the love of god, elaborate πŸ˜…
@lyse Please for the love of god, elaborate πŸ˜…
@lyse da fuq?! same here, what did you just reply to?! πŸ€”
@lyse da fuq?! same here, what did you just reply to?! πŸ€”
@lyse da hell are you replying to?! 🀣
@lyse da hell are you replying to?! 🀣
Offline backups currently cost me around ~$2.00 AUD per month.~
Offline backups currently cost me around ~$2.00 AUD per month.~
Spent the day performing backups (_hadn't done it in a while 😱_) and wrote a full backup definition internal document that defines my backup process, scope, security, frequency, backup locations, capacity and backup and restoration procedures. Very happy with the doc and the updated (_now fully documented_) plan and scheduled backup frequency (_once per month, which I'll put into my calendar as it's done by hand for now, with tools_). So far backing up ~410GB out of a possible ~12.8TB worth of data in two locations -- I deliberately don't backup everything as much of the data can be re-created (_music, videos, tv shows, etc_). #Backups #Data_
Spent the day performing backups (_hadn't done it in a while 😱_) and wrote a full backup definition internal document that defines my backup process, scope, security, frequency, backup locations, capacity and backup and restoration procedures. Very happy with the doc and the updated (_now fully documented_) plan and scheduled backup frequency (_once per month, which I'll put into my calendar as it's done by hand for now, with tools_). So far backing up ~410GB out of a possible ~12.8TB worth of data in two locations -- I deliberately don't backup everything as much of the data can be re-created (_music, videos, tv shows, etc_). #Backups #Data_
I'll share my opinion on this later 🀣
I'll share my opinion on this later 🀣
What do we think about this? πŸ˜…
What do we think about this? πŸ˜…
Swa this pop up in my Github news feed today πŸ€” Which links to https://github.com/musingstudio/go-subclub

> A Go (golang) library for interacting with the sub.club API.

So I got curious and had a peek πŸ‘€

> Let's fund the Fediverse
>> Posting or hosting on the open social networks no longer means you have to do it for free. Developer Preview now available.

And further down:

> Monetize your feeds
>> If you post quality content and you've developed a loyal audience, you should be able to ask your most passionate followers to support you with a premium subscription.
>>
>> That's a promise not available on the Fediverse ...until now.

Hmmm πŸ€”
Swa this pop up in my Github news feed today πŸ€” Which links to https://github.com/musingstudio/go-subclub

> A Go (golang) library for interacting with the sub.club API.

So I got curious and had a peek πŸ‘€

> Let's fund the Fediverse
>> Posting or hosting on the open social networks no longer means you have to do it for free. Developer Preview now available.

And further down:

> Monetize your feeds
>> If you post quality content and you've developed a loyal audience, you should be able to ask your most passionate followers to support you with a premium subscription.
>>
>> That's a promise not available on the Fediverse ...until now.

Hmmm πŸ€”
@slashdot I can only see a mass exodus of uses fleeing telegram as the service becomes less secure or less privacy focused and basically more shit.
@slashdot I can only see a mass exodus of uses fleeing telegram as the service becomes less secure or less privacy focused and basically more shit.
@quark cheers 🍻
@quark cheers 🍻
it might have made sense in the days of hose and buggy and smoke signals to centralise everything, but these days we have a globalized interconnected society with fast transport and communications. There is no reason for this model anymore 🀣
it might have made sense in the days of hose and buggy and smoke signals to centralise everything, but these days we have a globalized interconnected society with fast transport and communications. There is no reason for this model anymore 🀣
@slashdot Can we please stop this whole "Back to the Office" garbage nonsense?! 😱 If a job does not require the physical presence of a person(s) to perform their role, or they are not "customer facing" or in a job that's required to "serve the public", let's just stop this utter nonsense. As much as I want my shares in Cromwell to go up, I really don't care. Let the corporate office buildings burn to the ground for all I care, turn them into cheap housing estates or apartments. Why we ever thought centralizing in once place to live and work is beyond me πŸ€¦β€β™‚οΈ
@slashdot Can we please stop this whole "Back to the Office" garbage nonsense?! 😱 If a job does not require the physical presence of a person(s) to perform their role, or they are not "customer facing" or in a job that's required to "serve the public", let's just stop this utter nonsense. As much as I want my shares in Cromwell to go up, I really don't care. Let the corporate office buildings burn to the ground for all I care, turn them into cheap housing estates or apartments. Why we ever thought centralizing in once place to live and work is beyond me πŸ€¦β€β™‚οΈ
@cuaxolotl No you're not the only one. I do this too, I often think about a problem in my head, even imagine the code, sometimes for weeks, hell even months, before I even write a line of code πŸ§‘β€πŸ’»
@cuaxolotl No you're not the only one. I do this too, I often think about a problem in my head, even imagine the code, sometimes for weeks, hell even months, before I even write a line of code πŸ§‘β€πŸ’»
@lyse Thankfully it's quite cool here so far πŸ‘Œ
@lyse Thankfully it's quite cool here so far πŸ‘Œ
Interesting πŸ€”
Interesting πŸ€”
@bender That sucks 😒 Sorry to hear you didn't sleep well 😴
@bender That sucks 😒 Sorry to hear you didn't sleep well 😴
@bender I was in bed 🀣
@bender I was in bed 🀣
@bender Haha I aggressively unfollow feds that are like this now 🀣
@bender Haha I aggressively unfollow feds that are like this now 🀣
@falsifian Yes hit a Twt permalink URI and ask for application/ json
@falsifian Yes hit a Twt permalink URI and ask for application/ json
@lyse Uggh πŸ₯΅ That sounds awful and reminds me of our very odd little 3-day heat wave we had last week 😱
@lyse Uggh πŸ₯΅ That sounds awful and reminds me of our very odd little 3-day heat wave we had last week 😱
@bender Thanks! πŸ™‡β€β™‚οΈ
@bender Thanks! πŸ™‡β€β™‚οΈ
I see πŸ€” Thanks!
I see πŸ€” Thanks!
@movq This ☝️
@movq This ☝️
@bender Do you recall what you were clicking through? πŸ€¦β€β™‚οΈ
@bender Do you recall what you were clicking through? πŸ€¦β€β™‚οΈ
@falsifian You are totally right. The specs are at least "open enough" for us to consider that as an implementation detail. We, and by we I mean @movq @lyse @bender @xuu and others should discuss this in more detail I believe and try to see if we can agree on what we're trying to solve.

> Does yarnd provide an API for finding twts? Is it similar?

No, it doesn't. But yarns (_the search engine/crawler wrote_) seems more fitting here. It's been discussed before, the possibility of building a "Twtxt Register v1" compatible API for yarns. I _think_ a search engine + crawler + registry (_especially ones that can form a bit of a "distributed network_) are far more useful I _think_ in order to support the _actual_ decentralised Twtxt / Yarn ecosystem (_which is how I prefer to describe it_).
@falsifian You are totally right. The specs are at least "open enough" for us to consider that as an implementation detail. We, and by we I mean @movq @lyse @bender @xuu and others should discuss this in more detail I believe and try to see if we can agree on what we're trying to solve.

> Does yarnd provide an API for finding twts? Is it similar?

No, it doesn't. But yarns (_the search engine/crawler wrote_) seems more fitting here. It's been discussed before, the possibility of building a "Twtxt Register v1" compatible API for yarns. I _think_ a search engine + crawler + registry (_especially ones that can form a bit of a "distributed network_) are far more useful I _think_ in order to support the _actual_ decentralised Twtxt / Yarn ecosystem (_which is how I prefer to describe it_).
@falsifian Ahh but this is solved now with the new single shot fetch?
@falsifian Ahh but this is solved now with the new single shot fetch?
@bender I've sort of lost the plot here a bit πŸ€¦β€β™‚οΈ What's the problem we're trying to figure out? πŸ€”
@bender I've sort of lost the plot here a bit πŸ€¦β€β™‚οΈ What's the problem we're trying to figure out? πŸ€”
@falsifian You are however right that registries always had a "search" capability, amost others.
@falsifian You are however right that registries always had a "search" capability, amost others.
@movq Jenny hasn't changed the way it computes hashes has it? (yarnd certainly hasn't).
@movq Jenny hasn't changed the way it computes hashes has it? (yarnd certainly hasn't).
@falsifian I _think_ I'm missing something in my description. When I say "search engine" I also mean "with a crawler" that is able to self-discover feeds. A registry (_as designed today, or as the spec described_) required users to add their feeds to one or more registries, putting the burden on the user(s). I for example do not bother adding my feed to a registry (_which one would I add it to anyway?_)_
@falsifian I _think_ I'm missing something in my description. When I say "search engine" I also mean "with a crawler" that is able to self-discover feeds. A registry (_as designed today, or as the spec described_) required users to add their feeds to one or more registries, putting the burden on the user(s). I for example do not bother adding my feed to a registry (_which one would I add it to anyway?_)_
@falsifian to my knowledge registries were never designed to crawl the Twtxt space. If they did, they would be considered a search engine 🀣
@falsifian to my knowledge registries were never designed to crawl the Twtxt space. If they did, they would be considered a search engine 🀣
@falsifian So yes, you would ask a pod about the missing Twt by hash, or whatever. Pods do this already, even though there aren't that many now, so it maybe a bit less effective today. However it's more of a small/tiny "distributed" protocol, you ask _any_ pod.

On registries however, I think a registry is the wrong approach. I see far greater value in feed crawlers and search engines like the (_half baked one_) I built over at https://search.twtxt.net/
@falsifian So yes, you would ask a pod about the missing Twt by hash, or whatever. Pods do this already, even though there aren't that many now, so it maybe a bit less effective today. However it's more of a small/tiny "distributed" protocol, you ask _any_ pod.

On registries however, I think a registry is the wrong approach. I see far greater value in feed crawlers and search engines like the (_half baked one_) I built over at https://search.twtxt.net/
@bender Yes sir! πŸ‘Œ
@bender Yes sir! πŸ‘Œ
@bender I usually follow anyone and anything, then I unfollow when they turn out to be either not interesting or otherwise 🀣
@bender I usually follow anyone and anything, then I unfollow when they turn out to be either not interesting or otherwise 🀣
@mckinley Why is it so hard so you think? πŸ€” What's missing to make this an easy choice for folks? πŸ€”
@mckinley Why is it so hard so you think? πŸ€” What's missing to make this an easy choice for folks? πŸ€”