# 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 196264
# self = https://watcher.sour.is?offset=172656
# next = https://watcher.sour.is?offset=172756
# prev = https://watcher.sour.is?offset=172556
@movq Yes! Basically @david points out that if we mandate that authors should retain the original timestamp in their feed when adjusting content, making fixes, etc, that they retain the original timestamp and leave it unaltered. We already do this anyway, we just need to say so.
Now we have a situation where folks participating in a "conversation" (thread) with appropriate clients can automatically detect edits with almost 100% accuracy by mere fact that the next time they fetch a feed that contains an edit, they now see two versions of the Twt with two different hashes, but identical timestamps.
You can use the fetch time to approximate a "version number" and deal with the display (UX) appropriately.
I can't believe I didn't think of this before 🤦♂️
@movq Yes! Basically @david points out that if we mandate that authors should retain the original timestamp in their feed when adjusting content, making fixes, etc, that they retain the original timestamp and leave it unaltered. We already do this anyway, we just need to say so.
Now we have a situation where folks participating in a "conversation" (thread) with appropriate clients can automatically detect edits with almost 100% accuracy by mere fact that the next time they fetch a feed that contains an edit, they now see two versions of the Twt with two different hashes, but identical timestamps.
You can use the fetch time to approximate a "version number" and deal with the display (UX) appropriately.
I can't believe I didn't think of this before 🤦♂️
@doesnmtwt probably isn't the best client I'm afraid. It doesn't really cache twts by their key (hash) to display threads properly. Jenny however does 👌
@doesnmtwt probably isn't the best client I'm afraid. It doesn't really cache twts by their key (hash) to display threads properly. Jenny however does 👌
Yesterday's April weather offered nearly everything. Sun, rain, clouds, wind. Luckily, the rain wasn't too bad, we precautionally brought our rain jackets and took cover under some trees for 5-10 minutes. From then on, it alternated mostly between sunny and cloudy. Perfect conditions for photography.
The 16°C felt pretty cold with all the wind. Especially at the summit for a late lunch. The clouds covered the sun for almost the entire time and the wind blew hard. Being sweaty from the way up didn't help. The sun returned as soon as we packed up.
On the way home, it drizzled just a little bit, although the clouds were really dark. A nice surprise. All in all, we had a really nice hike. As a bonus, my mate established a new train ride record low to get home, despite all the Octoberfest crap going on right now.
Colorful leaves on a tree
From my 395 photos, I only kept 40: https://lyse.isobeef.org/waldspaziergang-2024-09-28/ In 18's upper left corner you can see a black beetle similar to what I've seen earlier this week. The one that rolled over its side to change directions, this one didn't, though.
The mushroom in 35 and 36 was enormous, easily 20 centimeters in diameter. We came across a few of them along our journey.
Only with dovecot xD. For mail im use android native mail client and not mutt. And jenny display some errors with found some files and /tmp dir (android dont have /tmp)
twet display twts in raw format with some formatting (sadly no newlines). And for reply messages i just seen (#hash). But which text hidden on hash? currenly im open twtxt.net/twt/hash to see this
@doesnm Thanks! I've almost come up with my own theme already 🤣 I _actually_ don't really want to use Hugo at all, I find it too complicated. But it is pretty popular so I _thought_ maybe I'd rip-off a nice theme... Hmmm 🧐
Anyway, What I really normally use for a lot of my static sites is zs
@doesnm Thanks! I've almost come up with my own theme already 🤣 I _actually_ don't really want to use Hugo at all, I find it too complicated. But it is pretty popular so I _thought_ maybe I'd rip-off a nice theme... Hmmm 🧐
Anyway, What I really normally use for a lot of my static sites is zs
Aujourd'hui, petits changements de formatage de mes documents sur le style RFC. Le titre apparaît désormais au centre et en haut de page. On a aussi la date de rédaction suivie de la date de dernière mise à jour. Que c'est beau :)
Aujourd'hui, petits changements de formatage de mes documents sur le style RFC. Le titre apparaît désormais au centre et en haut de page. On a aussi la date de rédaction suivie de la date de dernière mise à jour. Que c'est beau :)
👋 Thanks for joining us on our Sept monthly Yarn.social meetup today y'all 🙇♂️ We had @david@sorenpeter@doesnm@falsifian and @xuu 💪 Nice turn out! (_not all at once of course, as we normally run this over 4 hours as we span many time zones!_)
Things we talked about:
- Decentralised vs. Distributed - Use of SHA256 for Twt Hash(es) - We solved Edits! 🥳 - UUID(s) probably won't work! (_susceptible to sppofing_) - Helped @sorenpeter write some PHP to process/parse User-Agent and service his feed via a custom PHP script 😅 - @falsifian introduced himself 👌 - Talked about Merkle Trees 🌳
👋 Thanks for joining us on our Sept monthly Yarn.social meetup today y'all 🙇♂️ We had @david@sorenpeter@doesnm@falsifian and @xuu 💪 Nice turn out! (_not all at once of course, as we normally run this over 4 hours as we span many time zones!_)
Things we talked about:
- Decentralised vs. Distributed - Use of SHA256 for Twt Hash(es) - We solved Edits! 🥳 - UUID(s) probably won't work! (_susceptible to sppofing_) - Helped @sorenpeter write some PHP to process/parse User-Agent and service his feed via a custom PHP script 😅 - @falsifian introduced himself 👌 - Talked about Merkle Trees 🌳
- @lyse and @sorenpeter express simplicity. Both Lyse and Sorenpeter support location-based addressing. - @falsifian believes we should continue to develop ideas and extensions progressively over time like we've always done. - @david@quark and @bender would like a better user experience, especially when threads break due to edits, deletions or feed location changes. - @anth would like to see utf-8 mandated, and the threading model remain largely the same as it is today, which is primarily based on the convention of a Twt Subject anyway, Twt Hash(es) just make the threading "more precise". Anth also states that format, client and server specification/recommendations should be kept separate. - @movq@xuu sorry you two haven't said too much really, so I'm not too sure?
Overall, the 22 votes we've had on the poll from the community (_if you can call it a community?_) have clearly shown that:
- We continue to support content-based addressing. (65/35) - We think about formally supporting edits/deletes (60/40) - We do not increase the use of cryptography (_thworing things like authenticity and identity out the window_) (70/30)
And overall the NPS (_net promoter score_) of "Would I recommend Twtxt to a friend" is a whopping 7/10 (_which is crazy! 🤯_)
Let's have our monthly catch up soon™ (1hr) and discuss together. My own take on the direction we should take at this point is as follows:
- We continue to use hashing for the threading model. - We think about changing this to SHA-256 for simplicity. - We either adopt @anth's UUID approach or @lyse Dynamic URL approach. - We continue to incrementally/progressively improve things over time as @falsifian suggested. - We think about mandating utf-8 as @anth suggests which makes things so much easier for everyone. - We further discuss the merits/ideas of supporting formal Edit/Delete requests or other ways to better support this in some way.
- @lyse and @sorenpeter express simplicity. Both Lyse and Sorenpeter support location-based addressing. - @falsifian believes we should continue to develop ideas and extensions progressively over time like we've always done. - @david@quark and @bender would like a better user experience, especially when threads break due to edits, deletions or feed location changes. - @anth would like to see utf-8 mandated, and the threading model remain largely the same as it is today, which is primarily based on the convention of a Twt Subject anyway, Twt Hash(es) just make the threading "more precise". Anth also states that format, client and server specification/recommendations should be kept separate. - @movq@xuu sorry you two haven't said too much really, so I'm not too sure?
Overall, the 22 votes we've had on the poll from the community (_if you can call it a community?_) have clearly shown that:
- We continue to support content-based addressing. (65/35) - We think about formally supporting edits/deletes (60/40) - We do not increase the use of cryptography (_thworing things like authenticity and identity out the window_) (70/30)
And overall the NPS (_net promoter score_) of "Would I recommend Twtxt to a friend" is a whopping 7/10 (_which is crazy! 🤯_)
Let's have our monthly catch up soon™ (1hr) and discuss together. My own take on the direction we should take at this point is as follows:
- We continue to use hashing for the threading model. - We think about changing this to SHA-256 for simplicity. - We either adopt @anth's UUID approach or @lyse Dynamic URL approach. - We continue to incrementally/progressively improve things over time as @falsifian suggested. - We think about mandating utf-8 as @anth suggests which makes things so much easier for everyone. - We further discuss the merits/ideas of supporting formal Edit/Delete requests or other ways to better support this in some way.
@prologic 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;)
@prologic 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;)
@prologic 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;)
@prologic 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;)
If we want this though (_or some of us do_) I will probably have to make the hard decision here to just fork from Twtxt entirely and define a completely new spec. If we care about the UX we need a few properties (_some of which we have, some of which we don't have and some of which are "weak"_):
- Authenticity - Integrity - Precision
The last one involves _actually_ supporting the notion of "Edits" and "Deletes" IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is "Versioned Twts".
If we want this though (_or some of us do_) I will probably have to make the hard decision here to just fork from Twtxt entirely and define a completely new spec. If we care about the UX we need a few properties (_some of which we have, some of which we don't have and some of which are "weak"_):
- Authenticity - Integrity - Precision Versioning
The last one involves _actually_ supporting the notion of "Edits" and "Deletes" IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is "Versioned Twts".
If we want this though (_or some of us do_) I will probably have to make the hard decision here to just fork from Twtxt entirely and define a completely new spec. If we care about the UX we need a few properties (_some of which we have, some of which we don't have and some of which are "weak"_):
- Authenticity - Integrity - Precision Versioning
The last one involves _actually_ supporting the notion of "Edits" and "Deletes" IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is "Versioned Twts".
I think the only legit way of preventing this kind of "spoofing attack" would be:
> Digitally Sign Twts: Each Twt could be digitally signed using a private key associated with the UUID. The signature would be calculated over the concatenation of the UUID, timestamp, and content. The public key could be published along with the feed so anyone can verify the authenticity of the Twt by checking the signature. This approach ensures that only the true owner of the UUID (and the corresponding private key) can produce valid hashes.
Which leads us to more Cryptography. Something which y'all voted against.
I think the only legit way of preventing this kind of "spoofing attack" would be:
> Digitally Sign Twts: Each Twt could be digitally signed using a private key associated with the UUID. The signature would be calculated over the concatenation of the UUID, timestamp, and content. The public key could be published along with the feed so anyone can verify the authenticity of the Twt by checking the signature. This approach ensures that only the true owner of the UUID (and the corresponding private key) can produce valid hashes.
Which leads us to more Cryptography. Something which y'all voted against.
- A /twtxt.txt.sig (_detached signauture_) - Or a way to sign the # uuid = with a key that can be verified.
Hmmm and as I write this actually, I _think_ this doesn't work either, because you can still just copy it regardless. Hmmm @xuu help me out here? How do we prevent "spoofing"? 🤔
- A /twtxt.txt.sig (_detached signauture_) - Or a way to sign the # uuid = with a key that can be verified.
Hmmm and as I write this actually, I _think_ this doesn't work either, because you can still just copy it regardless. Hmmm @xuu help me out here? How do we prevent "spoofing"? 🤔
So far I'm using most of the tools directly from the command line, but I might take inspiration from https://sr.ht/~rakoo/omail/ to make my workflow a bit more efficient.
*To get any closer, I think I'd have to hand-craft my own SMTP client or something.
> That page says “For the best experience your client should also support some of the Twtxt Extensions…” but it is clear you don’t need to. I would like it to stay that way, and publishing a big long spec and calling it “twtxt v2” feels like a departure from that. (I think the content of the document is valuable; I’m just carping about how it’s being presented.)
It's for this reason I'd like to try changing the Twt Hash extension to use SHA-256 which is a far more common tool available pretty much everywhere. I _think_ the effort involved in "precise threading" (_using content addressing_) becomes much easier to "author" (_note that participating in an existing thread has always been trivial, just copy the Twt Subject in your Twt_).
> That page says “For the best experience your client should also support some of the Twtxt Extensions…” but it is clear you don’t need to. I would like it to stay that way, and publishing a big long spec and calling it “twtxt v2” feels like a departure from that. (I think the content of the document is valuable; I’m just carping about how it’s being presented.)
It's for this reason I'd like to try changing the Twt Hash extension to use SHA-256 which is a far more common tool available pretty much everywhere. I _think_ the effort involved in "precise threading" (_using content addressing_) becomes much easier to "author" (_note that participating in an existing thread has always been trivial, just copy the Twt Subject in your Twt_).
> Again, I like this existing simplicity. (I would even argue you don’t need the metadata.)
I argue you do. It's nice to have a "@nick@domain
It's also quite nice to have a visual representation of the feed too. description can be optional.
Without this, feeds are a bit too "bland" IMO.
> Again, I like this existing simplicity. (I would even argue you don’t need the metadata.)
I argue you do. It's nice to have a "@nick@domain
It's also quite nice to have a visual representation of the feed too. description can be optional.
Without this, feeds are a bit too "bland" IMO.
This is why we need "authenticity" 🤣 Yes if you copied my feed's UUID, then you'd end up generating identical hashes to me if we posted at identical times with identical timestamps. Not good 😌
This is why we need "authenticity" 🤣 Yes if you copied my feed's UUID, then you'd end up generating identical hashes to me if we posted at identical times with identical timestamps. Not good 😌
@bender It's the experience of an ordinary person in a strange place where memories are disappearing with the help of the Memory Police. The setting feels contemporary (to the book's 1994 publication date) rather than futuristic, except for some unexplained stuff about memories.
Colorful leaves on a tree
