# 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 60795
# self = https://watcher.sour.is?uri=https://twtxt.net/user/prologic/twtxt.txt&offset=57080
# next = https://watcher.sour.is?uri=https://twtxt.net/user/prologic/twtxt.txt&offset=57180
# prev = https://watcher.sour.is?uri=https://twtxt.net/user/prologic/twtxt.txt&offset=56980
Ever wondered what it would cost to self-hosted vs. use the cloud? Well I often doubt myself every time I look at hardware prices, and I know I have to do some hardware refresh soon™ for the Mills DC (_something I don't have a regular plan or budget for_), here's a rough ball park:

The Mills DC has cost me around ~$15k to build and maintain over the last ~10 years or so. Roughly speaking. I've never actually taken a Bill of Materials or anything, but I could if anyone is interested in more specifics.

The equivalent of resources if run in the "Cloud" would cost around:

- ~$1,000 for virtual machines
- ~$12000 for storage

So around ~$2,000/month to run.

Keep this in mind anytime anyone ever tries to con you into believing "Cloud is cheaper". It's not.~
Ever wondered what it would cost to self-hosted vs. use the cloud? Well I often doubt myself every time I look at hardware prices, and I know I have to do some hardware refresh soon™ for the Mills DC (_something I don't have a regular plan or budget for_), here's a rough ball park:

The Mills DC has cost me around ~$15k to build and maintain over the last ~10 years or so. Roughly speaking. I've never actually taken a Bill of Materials or anything, but I could if anyone is interested in more specifics.

The equivalent of resources if run in the "Cloud" would cost around:

- ~$1,000 for virtual machines
- ~$12000 for storage

So around ~$2,000/month to run.

Keep this in mind anytime anyone ever tries to con you into believing "Cloud is cheaper". It's not.~
@aelaraji This is one of the reasons why yarnd has a couple of settings with some sensible/sane defaults:

> I could already imagine a couple of extreme cases where, somewhere, in this peaceful world one’s exercise of freedom of speech could get them in Real trouble (if not danger) if found out, it wouldn’t necessarily have to involve something to do with Law or legal authorities. So, If someone asks, and maybe fearing fearing for… let’s just say ‘Their well being’, would it heart if a pod just purged their content if it’s serving it publicly (maybe relay the info to other pods) and call it a day? It doesn’t have to be about some law/convention somewhere … 🤷 I know! Too extreme, but I’ve seen news of people who’d gone to jail or got their lives ruined for as little as a silly joke. And it doesn’t even have to be about any of this.

There are two settings:


$ ./yarnd --help 2>&1 | grep max-cache
      --max-cache-fetchers int        set maximum numnber of fetchers to use for feed cache updates (default 10)
  -I, --max-cache-items int           maximum cache items (per feed source) of cached twts in memory (default 150)
  -C, --max-cache-ttl duration        maximum cache ttl (time-to-live) of cached twts in memory (default 336h0m0s)


So yarnd pods by default are designed to only keep Twts around publicly visible on either the anonymous Frontpage or Discover View or your Timeline or the feed's Timeline for up to 2 weeks with a maximum of 150 items, whichever get exceeded first. Any Twts over this are considered "old" and drop off the active cache.

It's a feature that my old man @off_grid_living was very strongly in support of, as was I back in the day of yarnd's design (_nothing particularly to do with Twtxt per se_) that I've to this day stuck by -- Even though there are _some_ 😉 that have different views on this 🤣
@aelaraji This is one of the reasons why yarnd has a couple of settings with some sensible/sane defaults:

> I could already imagine a couple of extreme cases where, somewhere, in this peaceful world one’s exercise of freedom of speech could get them in Real trouble (if not danger) if found out, it wouldn’t necessarily have to involve something to do with Law or legal authorities. So, If someone asks, and maybe fearing fearing for… let’s just say ‘Their well being’, would it heart if a pod just purged their content if it’s serving it publicly (maybe relay the info to other pods) and call it a day? It doesn’t have to be about some law/convention somewhere … 🤷 I know! Too extreme, but I’ve seen news of people who’d gone to jail or got their lives ruined for as little as a silly joke. And it doesn’t even have to be about any of this.

There are two settings:


$ ./yarnd --help 2>&1 | grep max-cache
      --max-cache-fetchers int        set maximum numnber of fetchers to use for feed cache updates (default 10)
  -I, --max-cache-items int           maximum cache items (per feed source) of cached twts in memory (default 150)
  -C, --max-cache-ttl duration        maximum cache ttl (time-to-live) of cached twts in memory (default 336h0m0s)


So yarnd pods by default are designed to only keep Twts around publicly visible on either the anonymous Frontpage or Discover View or your Timeline or the feed's Timeline for up to 2 weeks with a maximum of 150 items, whichever get exceeded first. Any Twts over this are considered "old" and drop off the active cache.

It's a feature that my old man @off_grid_living was very strongly in support of, as was I back in the day of yarnd's design (_nothing particularly to do with Twtxt per se_) that I've to this day stuck by -- Even though there are _some_ 😉 that have different views on this 🤣
@aelaraji Thanks for this! 🙏
@aelaraji Thanks for this! 🙏
Bahahahaha very clever @lyse I look forward to reading your report ! 🤣 However...


$ yarnc debug https://twtxt.net/user/prologic/twtxt.txt | grep -E '^pqst4ea' | tee | wc -l
0


I very quickly proved that Twt was never from me 🤣
Bahahahaha very clever @lyse I look forward to reading your report ! 🤣 However...


$ yarnc debug https://twtxt.net/user/prologic/twtxt.txt | grep -E '^pqst4ea' | tee | wc -l
0


I very quickly proved that Twt was never from me 🤣
@yarn_police Cool cool 🙇‍♂️
@yarn_police Cool cool 🙇‍♂️
@yarn_police What's going on?
@yarn_police What's going on?
@movq Yes that's true they are only integrity checks. But beyond a malicious pod (ignore yarnd'a gossiping protocol for now) how does what @lyse presented work exactly? 😅
@movq Yes that's true they are only integrity checks. But beyond a malicious pod (ignore yarnd'a gossiping protocol for now) how does what @lyse presented work exactly? 😅
But this is no different to how jenny does things with storing every Twt in a Maildir I suppose? 🤔
But this is no different to how jenny does things with storing every Twt in a Maildir I suppose? 🤔
This has specifically come up before in the form of "informal complaints" against yarnd because of the way it permanently stores and archives Twts, so even if you decide you changed your mind, or deleted that line out of your feed, if my pod or @xuu or @abucci or @eldersnake (_or any other handful of pods still around?_) saw the Twt, it'd be permanently archived._
This has specifically come up before in the form of "informal complaints" against yarnd because of the way it permanently stores and archives Twts, so even if you decide you changed your mind, or deleted that line out of your feed, if my pod or @xuu or @abucci or @eldersnake (_or any other handful of pods still around?_) saw the Twt, it'd be permanently archived._
Yeah I'm curious to find out too beyond just "here say". But regardless of whether we should or shouldn't care about this or should or shouldn't comply. We should IMO. I'd have to build something that horrendously violates someone's rights in another country.
Yeah I'm curious to find out too beyond just "here say". But regardless of whether we should or shouldn't care about this or should or shouldn't comply. We should IMO. I'd have to build something that horrendously violates someone's rights in another country.
@movq Care to explain how this explicit/attack works for me? 🤣
@movq Care to explain how this explicit/attack works for me? 🤣
Well that was bloody awful. This PR bokr my pod for some strange reason I can't figure out why or how 😱 The process just kept getting terminated from something, somewhere (_no panic_). weird. I've reverted this PR for now @xuu
Well that was bloody awful. This PR bokr my pod for some strange reason I can't figure out why or how 😱 The process just kept getting terminated from something, somewhere (_no panic_). weird. I've reverted this PR for now @xuu
Really though I only managed to save a few GB, but it's enough for now.
Really though I only managed to save a few GB, but it's enough for now.
@bender Haha 😛 Faster? Maybe 🤔 But yeah it's good to have backups! (_that work_)
@bender Haha 😛 Faster? Maybe 🤔 But yeah it's good to have backups! (_that work_)
I've also put up this PR [Add compatible methods for Index to behave as the Archiver (transition) #1177
](https://git.mills.io/yarnsocial/yarn/pulls/1177) that will act as a transition from the old naive archiver to the new bluge-based search/index. I will switch my pod over to this soon to test it before anyone else does.
I've also put up this PR [Add compatible methods for Index to behave as the Archiver (transition) #1177
](https://git.mills.io/yarnsocial/yarn/pulls/1177) that will act as a transition from the old naive archiver to the new bluge-based search/index. I will switch my pod over to this soon to test it before anyone else does.
For those curious, the archive on this pod had reached around ~22GB in size. I had to suck it down to my more powerful Mac Studio to clean it up and remove a bunch of junk. Then copy all the data back. This is what my local network traffic looked like for the last few hours 😱 ~
For those curious, the archive on this pod had reached around ~22GB in size. I had to suck it down to my more powerful Mac Studio to clean it up and remove a bunch of junk. Then copy all the data back. This is what my local network traffic looked like for the last few hours 😱 ~
And we're back. Sorry about that 😅
And we're back. Sorry about that 😅
@lyse Hmmm I'm not sure sure I get what you're getting at here. In order for this to be true, yarnd would have to be maliciously fabricating a Twt with the Hash D.
@lyse Hmmm I'm not sure sure I get what you're getting at here. In order for this to be true, yarnd would have to be maliciously fabricating a Twt with the Hash D.
i.e: there must be two versions of the Twt in the feed.
i.e: there must be two versions of the Twt in the feed.
@lyse This is true. But the client MUST supply the original too! Or this doesn't work 😢
@lyse This is true. But the client MUST supply the original too! Or this doesn't work 😢
If OTOH your client doesn't store individual Twts in a cache/archive or some kind of database, then verification becomes quite hard and tedious. However I think of this as an implementation details. The spec should just call out that clients must validate/verify the edit request and the matching hash actually exists in that feed, not how the client should implement that.
If OTOH your client doesn't store individual Twts in a cache/archive or some kind of database, then verification becomes quite hard and tedious. However I think of this as an implementation details. The spec should just call out that clients must validate/verify the edit request and the matching hash actually exists in that feed, not how the client should implement that.
@lyse Yes you do. You keep both versions in your cache. They have different hashes. So you have Twt A, a client indicates Twt B is an edit of A, your client has already seen A and cached and archived it, now your client fetches B which is indicated of editing A. You cache/archive B as well, but now indicate in your display that B replaces A (_maybe display, link both_) or just display B or whatever. But essentially you now have both, but an indicator of one being an edit of the other.

The right thing to do here of course is to keep A in the "thread" but display B. Why? So the thread/chain doesn't actually break or fork (_forking is a natural consequence of editing, or is it the other way around? 🤔_)._
@lyse Yes you do. You keep both versions in your cache. They have different hashes. So you have Twt A, a client indicates Twt B is an edit of A, your client has already seen A and cached and archived it, now your client fetches B which is indicated of editing A. You cache/archive B as well, but now indicate in your display that B replaces A (_maybe display, link both_) or just display B or whatever. But essentially you now have both, but an indicator of one being an edit of the other.

The right thing to do here of course is to keep A in the "thread" but display B. Why? So the thread/chain doesn't actually break or fork (_forking is a natural consequence of editing, or is it the other way around? 🤔_)._
@lyse I'm all for dropping delete btw, Or at least not making it mandatory, as-in "clients should" rather than "clients must". But yes I agree, let's explore all the possible ways this can be exploited (_if at all_).
@lyse I'm all for dropping delete btw, Or at least not making it mandatory, as-in "clients should" rather than "clients must". But yes I agree, let's explore all the possible ways this can be exploited (_if at all_).
@movq I think not.

> What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?

This gets too complicated if we start to support this kind of nonsense 🤣
@movq I think not.

> What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?

This gets too complicated if we start to support this kind of nonsense 🤣
@movq Thank you! 🙏
@movq Thank you! 🙏
@lyse Walk me through this? 🤔 I get what you're saying, but I'm too stupid to be a "hacker" 🤣
@lyse Walk me through this? 🤔 I get what you're saying, but I'm too stupid to be a "hacker" 🤣
But yes, at the end of the day if the edit request is invalid or cannot be verified, it should be ignored as treated as "malicious".
But yes, at the end of the day if the edit request is invalid or cannot be verified, it should be ignored as treated as "malicious".
@lyse @movq So a client that has the idea of a cache/archive wouldn't necessarily have to re-check that the Twt being marked as "edited" belongs to that feed or not, the client would already know that for sure. At least this is how yarnd works and I'm sure jenny can make similar assertions too.
@lyse @movq So a client that has the idea of a cache/archive wouldn't necessarily have to re-check that the Twt being marked as "edited" belongs to that feed or not, the client would already know that for sure. At least this is how yarnd works and I'm sure jenny can make similar assertions too.
@lyse @falsifian Contributions to search.twtxt.net, which runs yarns (_not to be confused with yarnd_) are always welcome 🤗 -- I don't have as much "spare time" as I used to due to the nature of my job (_Staff Engineer_); but I try to make improvements every now and again 💪
@lyse @falsifian Contributions to search.twtxt.net, which runs yarns (_not to be confused with yarnd_) are always welcome 🤗 -- I don't have as much "spare time" as I used to due to the nature of my job (_Staff Engineer_); but I try to make improvements every now and again 💪
@falsifian You make good points though, I made similar arguments about this too back in the day. Twtxt v2 / Yarn.social being at least ~4 years old now 😅~
@falsifian You make good points though, I made similar arguments about this too back in the day. Twtxt v2 / Yarn.social being at least ~4 years old now 😅~
@falsifian Do you have specifics about the GRPD law about this?

> Would the GDPR would apply to a one-person client like jenny? I seriously hope not. If someone asks me to delete an email they sent me, I don’t think I have to honour that request, no matter how European they are.

I'm not sure myself now. So let's find out whether parts of the GDPR actually apply to a truly decentralised system? 🤔
@falsifian Do you have specifics about the GRPD law about this?

> Would the GDPR would apply to a one-person client like jenny? I seriously hope not. If someone asks me to delete an email they sent me, I don’t think I have to honour that request, no matter how European they are.

I'm not sure myself now. So let's find out whether parts of the GDPR actually apply to a truly decentralised system? 🤔
LOL 😂 This:

> anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves

I'd like to see a step-by-step reproduction of this. I don't buy it 🤣

Admittedly yarnd had a few implementation security bugs, but I'm not sure this is actually possible, unless I'm missing something? 🤔
LOL 😂 This:

> anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves

I'd like to see a step-by-step reproduction of this. I don't buy it 🤣

Admittedly yarnd had a few implementation security bugs, but I'm not sure this is actually possible, unless I'm missing something? 🤔
@david Very nice! 👍
@david Very nice! 👍
@movq Ok 😅
@movq Ok 😅
@movq Hmmm not sure what I was thinking sorry 🤦‍♂️been a long day 😂
@movq Hmmm not sure what I was thinking sorry 🤦‍♂️been a long day 😂
@movq Am I missing something? 😅
@movq Am I missing something? 😅
@movq Precisely 👌
@movq Precisely 👌
@movq Is t it? You read each Twt and compute its hash. It's a simple O(1) lookup of the hash in that feed or your cache/archive right?
@movq Is t it? You read each Twt and compute its hash. It's a simple O(1) lookup of the hash in that feed or your cache/archive right?
👋 Reminder that next Saturday 28th September will be out monthly online meetup! Hope to see some/all of you there 👌
👋 Reminder that next Saturday 28th September will be out monthly online meetup! Hope to see some/all of you there 👌
I'll try to reproduce locally later tonight
I'll try to reproduce locally later tonight
@lyse I don't think this is true.
@lyse I don't think this is true.
@lyse No that's never a problem because we really only want to "navigate" the web anyway not form threads of xonversation 🤣
@lyse No that's never a problem because we really only want to "navigate" the web anyway not form threads of xonversation 🤣
@movq this approach also wouldn't work and when that Feed gets archived so you'll be forced to crawl archived feeds at that point.
@movq this approach also wouldn't work and when that Feed gets archived so you'll be forced to crawl archived feeds at that point.
The important bits missing from this summary (_devil is in the details_) are two requirements:

- Clients _should_ order Twts by their timestamp.
- Clients *must* validate all edit and delete requests that the hash being indicated belongs to and came from that feed.
- Client _should_ honour delete requests and delete Twts from their cache/archive.
The important bits missing from this summary (_devil is in the details_) are two requirements:

- Clients _should_ order Twts by their timestamp.
- Clients *must* validate all edit and delete requests that the hash being indicated belongs to and came from that feed.
- Client _should_ honour delete requests and delete Twts from their cache/archive.
@lyse This is why hashes provide that level of integrity. The hash can be verified in the cache or archive as belonging to said feed.
@lyse This is why hashes provide that level of integrity. The hash can be verified in the cache or archive as belonging to said feed.
@movq I think the order of the lines in a feed don't matter as long as we can guarantee the order of Twts. Clients should already be ordering by Timestamp anyway.
@movq I think the order of the lines in a feed don't matter as long as we can guarantee the order of Twts. Clients should already be ordering by Timestamp anyway.
@movq Pretry much 👌
@movq Pretry much 👌
@lyse Sorry could you explain this sifferently?
@lyse Sorry could you explain this sifferently?
Do you k ow what you clicked on before going back?
Do you k ow what you clicked on before going back?
@eldersnake Sweet thank you! 🙇‍♂️ I'll merge this PR tonight I think.
@eldersnake Sweet thank you! 🙇‍♂️ I'll merge this PR tonight I think.