# 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 196279
# self = https://watcher.sour.is?offset=171325
# next = https://watcher.sour.is?offset=171425
# prev = https://watcher.sour.is?offset=171225
@david Aye, I’ve pushed some commits. (And this is *really* going to be the last non-trivial change. 😂)
@david Aye, I’ve pushed some commits. (And this is *really* going to be the last non-trivial change. 😂)
@movq yes, that's perfect! <3
@movq yes, that's perfect! <3
[47°09′21″S, 126°43′56″W] Raw reading: 0x66EC4A81, offset +/-5
@eldersnake I wanted to ask you, are you running Headscale *and* WireGuard on the same VPS? I want to test Headscale, but currently run a small container with WireGuard, and I wonder if I need to stop (and eventually get rid of) the container to get Headscale going. Did you use the provided .deb to install Headscale, or some other method?
@eldersnake I wanted to ask you, are you running Headscale *and* WireGuard on the same VPS? I want to test Headscale, but currently run a small container with WireGuard, and I wonder if I need to stop (and eventually get rid of) the container to get Headscale going. Did you use the provided .deb to install Headscale, or some other method?
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
@david Yeah, I was annoyed by this myself lately. twts have become *so long* nowadays, it really gets in the way.
@david Yeah, I was annoyed by this myself lately. twts have become *so long* nowadays, it really gets in the way.
@david Yeah, I was annoyed by this myself lately. twts have become *so long* nowadays, it really gets in the way.
@david Yeah, I was annoyed by this myself lately. twts have become *so long* nowadays, it really gets in the way.
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
@prologic I read it. I understand it. Hopefully a solution can be agreed upon that solves the editing issue, whilst maintaining the cryptographic hash.
@prologic I read it. I understand it. Hopefully a solution can be agreed upon that solves the editing issue, whilst maintaining the cryptographic hash.
@prologic
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, it’s much less mysterious than that. 😅 The twt in question exists in your archived feed. It’s not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So that’s clearly an advantage of the current system.~
@prologic
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, it’s much less mysterious than that. 😅 The twt in question exists in your archived feed. It’s not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So that’s clearly an advantage of the current system.~
@prologic
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, it’s much less mysterious than that. 😅 The twt in question exists in your archived feed. It’s not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So that’s clearly an advantage of the current system.~
@prologic
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, it’s much less mysterious than that. 😅 The twt in question exists in your archived feed. It’s not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So that’s clearly an advantage of the current system.~
e.g: Shutdown yarnd and cp -a yarn.db yarn.db.bak before testing this PR/branch.
e.g: Shutdown yarnd and cp -a yarn.db yarn.db.bak before testing this PR/branch.
Can I get someone like maybe @xuu or @abucci or even @eldersnake -- If you have some spare time -- to test this yarnd PR that upgrades the Bitcask dependency for its internal database to v2? 🙏
VERY IMPORTANT If you do; Please Please Please backup your yarn.db database first! 😅 Heaven knows I don't want to be responsible for fucking up a production database here or there 🤣
Can I get someone like maybe @xuu or @abucci or even @eldersnake -- If you have some spare time -- to test this yarnd PR that upgrades the Bitcask dependency for its internal database to v2? 🙏
VERY IMPORTANT If you do; Please Please Please backup your yarn.db database first! 😅 Heaven knows I don't want to be responsible for fucking up a production database here or there 🤣
nevermind; I _think_ this might be some changes internally in Go 1.23 and a dependency I needed to update 🤞
nevermind; I _think_ this might be some changes internally in Go 1.23 and a dependency I needed to update 🤞
Location Addressing is fine in smaller or single systems. But when you're talking about large decentralised systems with no single point of control (_kind of the point_) things like independable variable integrity become quite important.
Location Addressing is fine in smaller or single systems. But when you're talking about large decentralised systems with no single point of control (_kind of the point_) things like independable variable integrity become quite important.
What is being proposed as a counter to content-addressing is called location-addressing. Two very different approaches, both with pros/cons of course. But a local cannot be verified, the content cannot be be guaranteed to be authenticate in any way, you just have to implicitly trust that the location points to the right thing.
What is being proposed as a counter to content-addressing is called location-addressing. Two very different approaches, both with pros/cons of course. But a local cannot be verified, the content cannot be be guaranteed to be authenticate in any way, you just have to implicitly trust that the location points to the right thing.
For example, without content-addressing, you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something 🤣 -- If that were the case, it would actually be possible to reconstruct the feed and verify every single Twt against the caches of all of you 🤣~
For example, without content-addressing, you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something 🤣 -- If that were the case, it would actually be possible to reconstruct the feed and verify every single Twt against the caches of all of you 🤣~
@david I _really_ thinks articles like this explain the benefits far better than I can.
@david I _really_ thinks articles like this explain the benefits far better than I can.
@prologic I know the role of the current hash is to allow referencing (replies and, thus, threads), and it also represents a "unique" way to verify a twtxt hasn't been tampered with. Is that second so important, if we are trying to allow edits? I know if feels good to be able to verify, but in reality, how often one does it?
@prologic I know the role of the current hash is to allow referencing (replies and, thus, threads), and it also represents a "unique" way to verify a twtxt hasn't been tampered with. Is that second so important, if we are trying to allow edits? I know if feels good to be able to verify, but in reality, how often one does it?
Terrón a través del túnel
#catsoftwtxt
Terrón a través del túnel
#catsoftwtxt
@movq could it be possible to have compressed_subject(msg_singlelined) be configurable, so only a certain number of characters get displayed, ending on ellipses? Right now the entire twtxt is crammed into the Subject:. This request aims to make twtxts display on mutt/neomutt, etc. more like emails do.
@movq could it be possible to have compressed_subject(msg_singlelined) be configurable, so only a certain number of characters get displayed, ending on ellipses? Right now the entire twtxt is crammed into the Subject:. This request aims to make twtxts display on mutt/neomutt, etc. more like emails do.
@david Witout including the content, it's no longer really "content addressing" now is it? You're essentially only addressing say nick+timestamp or url+timestamp.
@david Witout including the content, it's no longer really "content addressing" now is it? You're essentially only addressing say nick+timestamp or url+timestamp.
@prologic I don't trust Google with anything, sorry, pass. Oh, and you need to sign in on your Google Account (or whatever they call it these days).
@prologic I don't trust Google with anything, sorry, pass. Oh, and you need to sign in on your Google Account (or whatever they call it these days).
@prologic how about hashing a combination of nick/timestamp, or url/timestamp only, and not the twtxt content? On edit those will not change, so no breaking of threads. I know, I know, just adding noise here. :-P
@prologic how about hashing a combination of nick/timestamp, or url/timestamp only, and not the twtxt content? On edit those will not change, so no breaking of threads. I know, I know, just adding noise here. :-P
Speaking of AI tech (_sorry!_); Just came across this really cool tool built by some engineers at Google™ (_currently completely free to use without any signup_) called NotebookLM 👌 Looks really good for summarizing and talking to document 📃
Speaking of AI tech (_sorry!_); Just came across this really cool tool built by some engineers at Google™ (_currently completely free to use without any signup_) called NotebookLM 👌 Looks really good for summarizing and talking to document 📃
@eldersnake there has to be less reliance on a single point of failure. It is not so much about creating jobs in the US (which come with it, anyway), but about the ability to produce what's needed at home too. What's the trade off? Is it going to be a little bit more expensive to manufacture, perhaps?
@eldersnake there has to be less reliance on a single point of failure. It is not so much about creating jobs in the US (which come with it, anyway), but about the ability to produce what's needed at home too. What's the trade off? Is it going to be a little bit more expensive to manufacture, perhaps?
@eldersnake Yeah I'm looking forward to that myself 🤣 It'll be great to see where technology grow to a level of maturity and efficiency where you can run the tools on your own PC or Device and use it for what, so far, I've found it to be somewhat decent at; Auto-Complete, Search and Q&A.
@eldersnake Yeah I'm looking forward to that myself 🤣 It'll be great to see where technology grow to a level of maturity and efficiency where you can run the tools on your own PC or Device and use it for what, so far, I've found it to be somewhat decent at; Auto-Complete, Search and Q&A.
@prologic That's definitely a little less depressing, when thinking of it that way 🤣 Be interesting when the hype dies down.
I'm not the biggest Apple fan around, but that is pretty awesome.
[47°09′55″S, 126°43′53″W] Dosimeter fixed
i found this site by searching "thing-fish"
@sorenpeter I really don't think we can ignore the last ~3 years and a bit of this threading model working quite well for us as a community across a very diverse set of clients and platforms. We cannot just drop something that "mostly works just fine" for the sake of "simplicity". We have to weight up all the options. There are very real benefits to using content addressing here that really IMO shouldn't be disregarded so lightly that actually provide a lot of implicit value that users of various clients just don't get to see. I'd recommend reading up on the ideas behind content addressing before simply dismissing the Twt Hash spec entirely, it wasn't even written or formalised by me, but I understand how it works quite well 😅 The guy that wrote the spec was (is?) way smarter than I was back then, probably still is now 🤣~
@sorenpeter I really don't think we can ignore the last ~3 years and a bit of this threading model working quite well for us as a community across a very diverse set of clients and platforms. We cannot just drop something that "mostly works just fine" for the sake of "simplicity". We have to weight up all the options. There are very real benefits to using content addressing here that really IMO shouldn't be disregarded so lightly that actually provide a lot of implicit value that users of various clients just don't get to see. I'd recommend reading up on the ideas behind content addressing before simply dismissing the Twt Hash spec entirely, it wasn't even written or formalised by me, but I understand how it works quite well 😅 The guy that wrote the spec was (is?) way smarter than I was back then, probably still is now 🤣~
@quark It does not. That is why I'm advocating for not using hashes for treads, but a simpler link-back scheme.
@quark It does not. That is why I'm advocating for not using hashes for treads, but a simpler link-back scheme.
@quark It does not. That is why I'm advocating for not using hashes for treads, but a simpler link-back scheme.
@quark It does not. That is why I'm advocating for not using hashes for treads, but a simpler link-back scheme.
@falsifian Right I see. Yeah maybe we want to avoid that 🤣 I do kind of tend to agree with @xuu in another thread that there isn't actually anything wrong with our use of Blake2 at all really, but we may want to consider all our options.
@falsifian Right I see. Yeah maybe we want to avoid that 🤣 I do kind of tend to agree with @xuu in another thread that there isn't actually anything wrong with our use of Blake2 at all really, but we may want to consider all our options.
@xuu I don't think this is a lextwt problem tbh. Just the Markdown aprser that yarnd currently uses. twtxt2html uses Goldmark and appears to behave better 🤣
@xuu I don't think this is a lextwt problem tbh. Just the Markdown aprser that yarnd currently uses. twtxt2html uses Goldmark and appears to behave better 🤣
@xuu Long while back, I experimented with using similarity algorithms to detect if two Twts were similar enough to be considered an "Edit".
@xuu Long while back, I experimented with using similarity algorithms to detect if two Twts were similar enough to be considered an "Edit".
Right I see what you mean @xuu -- Can you maybe come up with a fully fleshed out proposal for this? 🤔 This will help solve the problem of hash collision that result from the Twt/hash space growing larger over time without us having to change anything about the way we construct hashes in the first place. We just assume spec compliant clients will just dynamically handle this as the space grows.
Right I see what you mean @xuu -- Can you maybe come up with a fully fleshed out proposal for this? 🤔 This will help solve the problem of hash collision that result from the Twt/hash space growing larger over time without us having to change anything about the way we construct hashes in the first place. We just assume spec compliant clients will just dynamically handle this as the space grows.
@xuu I _think_ we never progressed this idea further because we weren't sure how to tell if a hash collision would occur in the first place right? In other words, how does Client A know to expand a hash vs. Client B in a 100% decentralised way? 🤔
@xuu I _think_ we never progressed this idea further because we weren't sure how to tell if a hash collision would occur in the first place right? In other words, how does Client A know to expand a hash vs. Client B in a 100% decentralised way? 🤔
Plus these so-called "LLM"(s) have a pretty good grasp of the "shape" of language, so they _appear_ to be quite intelligent or produce intelligible response (_when they're actually quite stupid really_).
Plus these so-called "LLM"(s) have a pretty good grasp of the "shape" of language, so they _appear_ to be quite intelligent or produce intelligible response (_when they're actually quite stupid really_).
@eldersnake You don't get left behind at all 🤣 It's hyped up so much, it's not even funny anymore. Basically at this point (_so far at least_) I've concluded that all this GenAI / LLM stuff is just a fancy auto-complete and indexing + search reinvented 🤣
@eldersnake You don't get left behind at all 🤣 It's hyped up so much, it's not even funny anymore. Basically at this point (_so far at least_) I've concluded that all this GenAI / LLM stuff is just a fancy auto-complete and indexing + search reinvented 🤣
/https://duque-terron.cat/media/photos/IMG_2074.jpeg) #catsoftwtxt