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.~
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.~
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 ๐คฃ
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 ๐คฃ
$ 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 ๐คฃ
$ 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 ๐คฃ
jenny does things with storing every Twt in a Maildir I suppose? ๐ค
jenny does things with storing every Twt in a Maildir I suppose? ๐ค
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._
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._
](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.
](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.
~
~
yarnd would have to be maliciously fabricating a Twt with the Hash D.
yarnd would have to be maliciously fabricating a Twt with the Hash D.
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? ๐ค_)._
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? ๐ค_)._
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_).
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_).
> 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 ๐คฃ
> 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 ๐คฃ
yarnd works and I'm sure jenny can make similar assertions too.
yarnd works and I'm sure jenny can make similar assertions too.
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 ๐ช
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 ๐ช
> 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? ๐ค
> 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? ๐ค
> 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? ๐ค
> 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? ๐ค
- 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.
- 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.