Fresh hay bales on a field
A screenshot of two "Dunst" notifications sent from a bash script showing how many unread twts and twtxt mentions I have in my inbox.
A screenshot of two "Dunst" notifications sent from a bash script showing how many unread twts and twtxt mentions I have in my inbox.
A screenshot of two "Dunst" notifications sent from a bash script showing how many unread twts and twtxt mentions I have in my inbox.
With the
(replyto:…) proposal, clients cannot indicate that a twt was edited *in the long run*. Clients can, of course, show that *right now*, but when they clean their cache and refetch feeds, the information is lost. This can be abused by malicious actors *if sufficient time has passed* (clients must have purged their cache): Malicious actors can change root twts and thus change the meaning of thread/replies.Is this a showstopper for you? 🤔
With the
(replyto:…) proposal, clients cannot indicate that a twt was edited *in the long run*. Clients can, of course, show that *right now*, but when they clean their cache and refetch feeds, the information is lost. This can be abused by malicious actors *if sufficient time has passed* (clients must have purged their cache): Malicious actors can change root twts and thus change the meaning of thread/replies.Is this a showstopper for you? 🤔
With the
(replyto:…) proposal, clients cannot indicate that a twt was edited *in the long run*. Clients can, of course, show that *right now*, but when they clean their cache and refetch feeds, the information is lost. This can be abused by malicious actors *if sufficient time has passed* (clients must have purged their cache): Malicious actors can change root twts and thus change the meaning of thread/replies.Is this a showstopper for you? 🤔
With the
(replyto:…) proposal, clients cannot indicate that a twt was edited *in the long run*. Clients can, of course, show that *right now*, but when they clean their cache and refetch feeds, the information is lost. This can be abused by malicious actors *if sufficient time has passed* (clients must have purged their cache): Malicious actors can change root twts and thus change the meaning of thread/replies.Is this a showstopper for you? 🤔
(edit:) spec has similar problems in its current form:1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with
(delete:), just remove the line.6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.
This raises two questions:
- The easy question: What do we do when the twt that an
(edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the
(replyto:) situation, I think. 🤔
(edit:) spec has similar problems in its current form:1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with
(delete:), just remove the line.6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.
This raises two questions:
- The easy question: What do we do when the twt that an
(edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the
(replyto:) situation, I think. 🤔
(edit:) spec has similar problems in its current form:1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with
(delete:), just remove the line.6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.
This raises two questions:
- The easy question: What do we do when the twt that an
(edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the
(replyto:) situation, I think. 🤔
(edit:) spec has similar problems in its current form:1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
5. Delete your first update from your feed, the one with the birds. Not with
(delete:), just remove the line.6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.
This raises two questions:
- The easy question: What do we do when the twt that an
(edit:) line refers to is removed *later on* from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.- The result being a thread without a root, just like it is today. That’s fine.
- The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the
(replyto:) situation, I think. 🤔
> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?
Then the content of that root twt changes. Just like it would with
(edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.In other words, we can’t (reliably) show a little star
* like on Mastodon to indicate edits.
> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?
Then the content of that root twt changes. Just like it would with
(edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.In other words, we can’t (reliably) show a little star
* like on Mastodon to indicate edits.
> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?
Then the content of that root twt changes. Just like it would with
(edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.In other words, we can’t (reliably) show a little star
* like on Mastodon to indicate edits.
> I just realized the other big property you lose is:
>
> > What if someone completely changes the content of the root of the thread?
>
> Does the Subject reference the feed and timestamp only or the intent too?
Then the content of that root twt changes. Just like it would with
(edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.In other words, we can’t (reliably) show a little star
* like on Mastodon to indicate edits.
Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈
> - Twt Subjects lose their meaning
You mean existing threads in the past? Yeah.
> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.
Not sure what you mean? 🤔 But yes, things can change (that’s the point).
> - Two persons cannot reply to a Twt independently of each other anymore.
How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:
(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar
Am I missing something?
Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈
> - Twt Subjects lose their meaning
You mean existing threads in the past? Yeah.
> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.
Not sure what you mean? 🤔 But yes, things can change (that’s the point).
> - Two persons cannot reply to a Twt independently of each other anymore.
How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:
(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar
Am I missing something?
Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈
> - Twt Subjects lose their meaning
You mean existing threads in the past? Yeah.
> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.
Not sure what you mean? 🤔 But yes, things can change (that’s the point).
> - Two persons cannot reply to a Twt independently of each other anymore.
How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:
(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar
Am I missing something?
Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈
> - Twt Subjects lose their meaning
You mean existing threads in the past? Yeah.
> - Twt Subjects cannot be verified without looking up the feed.
> - Which may or may not exist anymore or may change.
Not sure what you mean? 🤔 But yes, things can change (that’s the point).
> - Two persons cannot reply to a Twt independently of each other anymore.
How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:
(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar
Am I missing something?
> What if someone completely changes the content of the root of the thread?
Does the Subject reference the feed and timestamp only or the intent too?
> What if someone completely changes the content of the root of the thread?
Does the Subject reference the feed and timestamp only or the intent too?
- Twt Subjects lose their meaning.
- Twt Subjects cannot be verified without looking up the feed.
- Which may or may not exist anymore or may change.
- Two persons cannot reply to a Twt independently of each other anymore.
_and probably some other properties we'd stand to lose that I'm forgetting about..._
- Twt Subjects lose their meaning.
- Twt Subjects cannot be verified without looking up the feed.
- Which may or may not exist anymore or may change.
- Two persons cannot reply to a Twt independently of each other anymore.
_and probably some other properties we'd stand to lose that I'm forgetting about..._
(replyto:...) as well. If the feed changes, well, it is the same as changing emails (and deleting the old one). No?
(replyto:…) proposal (_location addressing vs. content addressing_) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your thread's "identifiers" are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how "forking" works in the first place.I realise this is a bit pret here, and it probably doesn't matter a whole lot at our size. But I'm trying to think way ahead, to a point where Twtxt as a "thing" can continue to work and function decades from now, even with the extensions we've built. We've already proven for example that Twts and threads from ~4 years ago still work and are easily looked up haha 😝~
(replyto:…) proposal (_location addressing vs. content addressing_) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your thread's "identifiers" are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how "forking" works in the first place.I realise this is a bit pret here, and it probably doesn't matter a whole lot at our size. But I'm trying to think way ahead, to a point where Twtxt as a "thing" can continue to work and function decades from now, even with the extensions we've built. We've already proven for example that Twts and threads from ~4 years ago still work and are easily looked up haha 😝~
(replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
(replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
(replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
(replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to *add* stuff to the protocol.I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.
-
(replyto:…) is twtxt-style-
(edit:…) and (delete:…) is Yarn-style
-
(replyto:…) is twtxt-style-
(edit:…) and (delete:…) is Yarn-style
-
(replyto:…) is twtxt-style-
(edit:…) and (delete:…) is Yarn-style
-
(replyto:…) is twtxt-style-
(edit:…) and (delete:…) is Yarn-style
- https://git.mills.io/yarnsocial/yarn/pulls/1179 –
(replyto:…)- https://git.mills.io/yarnsocial/yarn/pulls/1180 –
(edit:…) and (delete:…)As a first step, this summarizes my current understanding. Please comment! 😊
- https://git.mills.io/yarnsocial/yarn/pulls/1179 –
(replyto:…)- https://git.mills.io/yarnsocial/yarn/pulls/1180 –
(edit:…) and (delete:…)As a first step, this summarizes my current understanding. Please comment! 😊
- https://git.mills.io/yarnsocial/yarn/pulls/1179 –
(replyto:…)- https://git.mills.io/yarnsocial/yarn/pulls/1180 –
(edit:…) and (delete:…)As a first step, this summarizes my current understanding. Please comment! 😊
- https://git.mills.io/yarnsocial/yarn/pulls/1179 –
(replyto:…)- https://git.mills.io/yarnsocial/yarn/pulls/1180 –
(edit:…) and (delete:…)As a first step, this summarizes my current understanding. Please comment! 😊
/https://baldo.cat/media/photos/IMG_2053.jpeg) #catsoftwtxt
#catsoftwtxt
#catsoftwtxt
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 🤣
I'm no lawyer, but my uneducated guess would be that:
A) twts are already publicly available/public knowledge and such... just don't process children's personal data and _MAYBE_ you're good? Since there's this:
> ... an organization’s right to process someone’s data might override their right to be forgotten. Here are the reasons cited in the GDPR that trump the right to erasure:
> - The data is being used to exercise the right of freedom of expression and information.
> - The data is being used to perform a task that is being carried out in the public interest or when exercising an organization’s official authority.
> - The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.
B) What I love about the TWTXT sphere is it's Human/Humane element! No deceptive algorithms, no Corpo B.S ...etc. Just Humans. So maybe ... If we thought about it in this way, it wouldn't heart to be even nicer to others/offering strangers an even safer space.
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.
P.S: Maybe make
X tool check out robots.txt? Or maybe make long-term archives Opt-in? Opt-out? P.P.S: Already Way too many MAYBE's in a single twt! So I'll just shut up. 😅
I'm no lawyer, but my uneducated guess would be that:
A) twts are already publicly available/public knowledge and such... just don't process children's personal data and _MAYBE_ you're good? Since there's this:
> ... an organization’s right to process someone’s data might override their right to be forgotten. Here are the reasons cited in the GDPR that trump the right to erasure:
> - The data is being used to exercise the right of freedom of expression and information.
> - The data is being used to perform a task that is being carried out in the public interest or when exercising an organization’s official authority.
> - The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.
B) What I love about the TWTXT sphere is it's Human/Humane element! No deceptive algorithms, no Corpo B.S ...etc. Just Humans. So maybe ... If we thought about it in this way, it wouldn't heart to be even nicer to others/offering strangers an even safer space.
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.
P.S: Maybe make
X tool check out robots.txt? Or maybe make long-term archives Opt-in? Opt-out? P.P.S: Already Way too many MAYBE's in a single twt! So I'll just shut up. 😅
I'm no lawyer, but my uneducated guess would be that:
A) twts are already publicly available/public knowledge and such... just don't process children's personal data and _MAYBE_ you're good? Since there's this:
> ... an organization’s right to process someone’s data might override their right to be forgotten. Here are the reasons cited in the GDPR that trump the right to erasure:
> - The data is being used to exercise the right of freedom of expression and information.
> - The data is being used to perform a task that is being carried out in the public interest or when exercising an organization’s official authority.
> - The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.
B) What I love about the TWTXT sphere is it's Human/Humane element! No deceptive algorithms, no Corpo B.S ...etc. Just Humans. So maybe ... If we thought about it in this way, it wouldn't heart to be even nicer to others/offering strangers an even safer space.
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.
P.S: Maybe make
X tool check out robots.txt? Or maybe make long-term archives Opt-in? Opt-out? P.P.S: Already Way too many MAYBE's in a single twt! So I'll just shut up. 😅
$ 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 🤣
Our investigations revealed: https://lyse.isobeef.org/tmp/twtinjector.tar.bz2
> In order for this to be true,
yarnd would have to be maliciously fabricating a Twt with the Hash D.Yep, that’s one way.
Now, I have *no idea* how any of the gossipping stuff in Yarn works, but maybe a malicious pod could also inject such a fabricated twt into *your* cache by gossipping it?
Either way, hashes are just integrity checks basically, not proof that a certain feed published a certain twt.
> In order for this to be true,
yarnd would have to be maliciously fabricating a Twt with the Hash D.Yep, that’s one way.
Now, I have *no idea* how any of the gossipping stuff in Yarn works, but maybe a malicious pod could also inject such a fabricated twt into *your* cache by gossipping it?
Either way, hashes are just integrity checks basically, not proof that a certain feed published a certain twt.
> In order for this to be true,
yarnd would have to be maliciously fabricating a Twt with the Hash D.Yep, that’s one way.
Now, I have *no idea* how any of the gossipping stuff in Yarn works, but maybe a malicious pod could also inject such a fabricated twt into *your* cache by gossipping it?
Either way, hashes are just integrity checks basically, not proof that a certain feed published a certain twt.
> In order for this to be true,
yarnd would have to be maliciously fabricating a Twt with the Hash D.Yep, that’s one way.
Now, I have *no idea* how any of the gossipping stuff in Yarn works, but maybe a malicious pod could also inject such a fabricated twt into *your* cache by gossipping it?
Either way, hashes are just integrity checks basically, not proof that a certain feed published a certain twt.
jenny does things with storing every Twt in a Maildir I suppose? 🤔