> This scope of changes is much easier to implement for
yarnd and *I suspect jenny too.*No,
(edit:) is a lot of work for jenny and also adds a lot of overhead.Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesn’t need to. This information only exists in the mail files. This means I can’t check if an
(edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isn’t great either).I’ve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. I’ll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didn’t reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of “just create some mail files” doesn’t really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big “meh”.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. There’s no easy way out.
Maybe I could say jenny does not support
(edit:) for now. That’s the good thing about this proposal: I don’t have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they won’t see twt updates, but nothing will break.
> This scope of changes is much easier to implement for
yarnd and *I suspect jenny too.*No,
(edit:) is a lot of work for jenny and also adds a lot of overhead.Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesn’t need to. This information only exists in the mail files. This means I can’t check if an
(edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isn’t great either).I’ve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. I’ll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didn’t reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of “just create some mail files” doesn’t really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big “meh”.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. There’s no easy way out.
Maybe I could say jenny does not support
(edit:) for now. That’s the good thing about this proposal: I don’t have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they won’t see twt updates, but nothing will break.
> This scope of changes is much easier to implement for
yarnd and *I suspect jenny too.*No,
(edit:) is a lot of work for jenny and also adds a lot of overhead.Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesn’t need to. This information only exists in the mail files. This means I can’t check if an
(edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isn’t great either).I’ve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. I’ll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didn’t reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of “just create some mail files” doesn’t really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big “meh”.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. There’s no easy way out.
Maybe I could say jenny does not support
(edit:) for now. That’s the good thing about this proposal: I don’t have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they won’t see twt updates, but nothing will break.
> This scope of changes is much easier to implement for
yarnd and *I suspect jenny too.*No,
(edit:) is a lot of work for jenny and also adds a lot of overhead.Right now, jenny itself has no idea which twt hashes are present on which feed, because it doesn’t need to. This information only exists in the mail files. This means I can’t check if an
(edit:) operation is legal. jenny will have to get an sqlite database (or read/parse/write 1-2 MB of JSON on every invocation, which isn’t great either).I’ve already spent several hours this morning rewriting the feed fetching/parsing code in an effort to pave the way to even be *able* to support any of this. I’ll spare you the details. Until now, twts were individual items in a feed, they could be processed in any order and they didn’t reference each other *from jennys point of view*. A lot of the heavy lifting happens in the mail client.
Honestly, the database thing bugs me the most. The whole concept of “just create some mail files” doesn’t really work anymore. I now have to duplicate state between the mail files and an internal database. This is a big “meh”.
Of course, if we were to switch to location-based addressing, then *you* would have to do a lot of work. There’s no easy way out.
Maybe I could say jenny does not support
(edit:) for now. That’s the good thing about this proposal: I don’t have to implement it right away. Users will see spurious twts (or I could hide them as a workaround) and they won’t see twt updates, but nothing will break.
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) @shreyan Ahh 👌]
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) @shreyan Ahh 👌]
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) @shreyan Ahh 👌]
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) @shreyan Ahh 👌]
$ ./stats
Saw 58263 hashes
7fqcxaa
https://twtxt.net/user/justamoment/twtxt.txt
https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
https://twtxt.net/user/prologic/twtxt.txt
https://twtxt.net/user/thecanine/twtxt.txt
Namely:
$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa
\n \n [(#pmuqoca) @prologic I checked the GitHub discussion, it became a request to join forces.
Do you plan on having them join?
Also for the name, how about:
- "progit" or "prologit" (prologic official hard fork)
- "git-stance" (git instance)
- "GitTree" (Gitea inspired, maybe to related)
- "Gitomata" (git automata)
- "Git.Source"
- "Forgor" (forgit is taken so I forgor) 🤣
- "SweetGit" (as salty chat)
- "Pepper Git" (other ingredients) 😉
- "GitHeart" (core of git with a GitHub sounding name)
- "GitTaka" (With music in mind)
Ok, enough fun... Hope this helps sprout some ideas from others if nothing is to your taste.]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa
\n \n [(#bqq6fxq) It's handled by blue Monday]
And:
$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
\n \n [(#2wh7r4q) @prologic I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
\n \n [(#otuupfq) @shreyan Ahh 👌]
(#<DATETIME URL>) would also work, yeah.
(#<DATETIME URL>) would also work, yeah.
(#<DATETIME URL>) would also work, yeah.
(#<DATETIME URL>) would also work, yeah.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like
(replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like
(replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like
(replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like
(replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for *massive spam* and I think we’re safe on that.
It’s easy to get lost in these scenarios and overshoot the target.
I’ll begin experimenting in jenny with Update Commands and see how bad it gets. I’ve already determined that my storage model wouldn’t work anymore. It’s all *doable*, but, like you, I’m not that happy with all the consequences. 😂
I’ll begin experimenting in jenny with Update Commands and see how bad it gets. I’ve already determined that my storage model wouldn’t work anymore. It’s all *doable*, but, like you, I’m not that happy with all the consequences. 😂
I’ll begin experimenting in jenny with Update Commands and see how bad it gets. I’ve already determined that my storage model wouldn’t work anymore. It’s all *doable*, but, like you, I’m not that happy with all the consequences. 😂
I’ll begin experimenting in jenny with Update Commands and see how bad it gets. I’ve already determined that my storage model wouldn’t work anymore. It’s all *doable*, but, like you, I’m not that happy with all the consequences. 😂
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?
(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! 😊
> 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.
I *think* none of this matters to people outside the EU anyway. These aren’t your laws. Even if you were to start a company in the US, it would only be a marketing instrument for you: “Hey, look, we follow GDPR!” EU people might then be more inclined to become your customers. But that’s it.
That said, I’m not sure anymore if there are any *other* treaties between the EU and the US which cover such things …
I *think* none of this matters to people outside the EU anyway. These aren’t your laws. Even if you were to start a company in the US, it would only be a marketing instrument for you: “Hey, look, we follow GDPR!” EU people might then be more inclined to become your customers. But that’s it.
That said, I’m not sure anymore if there are any *other* treaties between the EU and the US which cover such things …
I *think* none of this matters to people outside the EU anyway. These aren’t your laws. Even if you were to start a company in the US, it would only be a marketing instrument for you: “Hey, look, we follow GDPR!” EU people might then be more inclined to become your customers. But that’s it.
That said, I’m not sure anymore if there are any *other* treaties between the EU and the US which cover such things …
I *think* none of this matters to people outside the EU anyway. These aren’t your laws. Even if you were to start a company in the US, it would only be a marketing instrument for you: “Hey, look, we follow GDPR!” EU people might then be more inclined to become your customers. But that’s it.
That said, I’m not sure anymore if there are any *other* treaties between the EU and the US which cover such things …
Maybe it’s time to draft all this into a spec or, rather, two different specs. I might do that over the weekend.
Maybe it’s time to draft all this into a spec or, rather, two different specs. I might do that over the weekend.
Maybe it’s time to draft all this into a spec or, rather, two different specs. I might do that over the weekend.
Maybe it’s time to draft all this into a spec or, rather, two different specs. I might do that over the weekend.
An edit twt would look like this:
2024-09-20T14:57:11Z (edit:#123467) foobar
So we now have to verify that
#123467 actually exists in this same feed. How do we do that? We must build a list of all twts/hashes of this feed and then check if #123467 is in that list. Right?You’re kind of implying that it would be possible to cryptographically validate that this hash belongs to this feed. That’s not possible, is it? 🤔
An edit twt would look like this:
2024-09-20T14:57:11Z (edit:#123467) foobar
So we now have to verify that
#123467 actually exists in this same feed. How do we do that? We must build a list of all twts/hashes of this feed and then check if #123467 is in that list. Right?You’re kind of implying that it would be possible to cryptographically validate that this hash belongs to this feed. That’s not possible, is it? 🤔
An edit twt would look like this:
2024-09-20T14:57:11Z (edit:#123467) foobar
So we now have to verify that
#123467 actually exists in this same feed. How do we do that? We must build a list of all twts/hashes of this feed and then check if #123467 is in that list. Right?You’re kind of implying that it would be possible to cryptographically validate that this hash belongs to this feed. That’s not possible, is it? 🤔
An edit twt would look like this:
2024-09-20T14:57:11Z (edit:#123467) foobar
So we now have to verify that
#123467 actually exists in this same feed. How do we do that? We must build a list of all twts/hashes of this feed and then check if #123467 is in that list. Right?You’re kind of implying that it would be possible to cryptographically validate that this hash belongs to this feed. That’s not possible, is it? 🤔
(replyto:…) over (edit:#): (replyto:…) relies on clients always processing the entire feed – otherwise they wouldn’t even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.I guess neither matters that much in practice. It’s still a disadvantage.
(replyto:…) over (edit:#): (replyto:…) relies on clients always processing the entire feed – otherwise they wouldn’t even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.I guess neither matters that much in practice. It’s still a disadvantage.
(replyto:…) over (edit:#): (replyto:…) relies on clients always processing the entire feed – otherwise they wouldn’t even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.I guess neither matters that much in practice. It’s still a disadvantage.
(replyto:…) over (edit:#): (replyto:…) relies on clients always processing the entire feed – otherwise they wouldn’t even notice when a twt gets updated. a) This is more expensive, b) you cannot edit twts once they get rotated into an archived feed, because there is nothing signalling clients that they have to re-fetch that archived feed.I guess neither matters that much in practice. It’s still a disadvantage.
.git directory. Last time I did that was over 11 years ago. 😅 (I often give introductions about Git, but they’re about day to day usage and very high-level.)I’ve gotta say, Git is one of the very few pieces of software that I love using and teaching. The files on your disk follow a simple enough format/pattern and you can actually teach people how it all works and, for example, *why* things like rebasing produce a particular result. 👌
.git directory. Last time I did that was over 11 years ago. 😅 (I often give introductions about Git, but they’re about day to day usage and very high-level.)I’ve gotta say, Git is one of the very few pieces of software that I love using and teaching. The files on your disk follow a simple enough format/pattern and you can actually teach people how it all works and, for example, *why* things like rebasing produce a particular result. 👌
.git directory. Last time I did that was over 11 years ago. 😅 (I often give introductions about Git, but they’re about day to day usage and very high-level.)I’ve gotta say, Git is one of the very few pieces of software that I love using and teaching. The files on your disk follow a simple enough format/pattern and you can actually teach people how it all works and, for example, *why* things like rebasing produce a particular result. 👌
.git directory. Last time I did that was over 11 years ago. 😅 (I often give introductions about Git, but they’re about day to day usage and very high-level.)I’ve gotta say, Git is one of the very few pieces of software that I love using and teaching. The files on your disk follow a simple enough format/pattern and you can actually teach people how it all works and, for example, *why* things like rebasing produce a particular result. 👌
> So, what would happen if there is no original message anymore in the feed and you encounter an "edit" subject?
We’d *have to* classify this as invalid and discard it. If the referenced twt is not present in the feed (or any archived feed), then it might potentially belong to some other feed, and feeds overwriting the contents of other feeds is pretty bad. 😅
As @prologic said, clients must always check that twts referenced by
edit and delete are actually present in that very feed.