# 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 15156
# self = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=12675
# next = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=12775
# prev = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=12575
@prologic Kind of. But the (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. 🤔
@prologic Kind of. But the (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. 🤔
@prologic Kind of. But the (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. 🤔
@prologic Kind of. But the (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. 🤔
@prologic
> 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.
@prologic
> 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.
@prologic
> 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.
@prologic
> 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.
@prologic
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?
@prologic
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?
@prologic
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?
@prologic
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?
I’m still more in favor of (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.
I’m still more in favor of (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.
I’m still more in favor of (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.
I’m still more in favor of (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.
Guess you could say:
- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
Guess you could say:
- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
Guess you could say:
- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
Guess you could say:
- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
@prologic I only saw your previous twt right now. You said:
> 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.
@prologic I only saw your previous twt right now. You said:
> 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.
@prologic I only saw your previous twt right now. You said:
> 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.
@prologic I only saw your previous twt right now. You said:
> 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.
@lyse Yeah, makes sense. You don’t even need hash collisions for that. 🤔 (I guess only individually signed twts would prevent that. 🙈 Yet another can of worms.)
@lyse Yeah, makes sense. You don’t even need hash collisions for that. 🤔 (I guess only individually signed twts would prevent that. 🙈 Yet another can of worms.)
@lyse Yeah, makes sense. You don’t even need hash collisions for that. 🤔 (I guess only individually signed twts would prevent that. 🙈 Yet another can of worms.)
@lyse Yeah, makes sense. You don’t even need hash collisions for that. 🤔 (I guess only individually signed twts would prevent that. 🙈 Yet another can of worms.)
@falsifian I’m curious myself now and might look it up (or even ask some of our legal guys/gals 😅).
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 …
@falsifian I’m curious myself now and might look it up (or even ask some of our legal guys/gals 😅).
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 …
@falsifian I’m curious myself now and might look it up (or even ask some of our legal guys/gals 😅).
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 …
@falsifian I’m curious myself now and might look it up (or even ask some of our legal guys/gals 😅).
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 …
@lyse I think that’s what we would *have to* enforce – otherwise we’d run into the problem you’ve outlined. 😃
@lyse I think that’s what we would *have to* enforce – otherwise we’d run into the problem you’ve outlined. 😃
@lyse I think that’s what we would *have to* enforce – otherwise we’d run into the problem you’ve outlined. 😃
@lyse I think that’s what we would *have to* enforce – otherwise we’d run into the problem you’ve outlined. 😃
@falsifian I think we’re talking about different ideas here. 🤔
Maybe it’s time to draft all this into a spec or, rather, two different specs. I might do that over the weekend.
@falsifian I think we’re talking about different ideas here. 🤔
Maybe it’s time to draft all this into a spec or, rather, two different specs. I might do that over the weekend.
@falsifian I think we’re talking about different ideas here. 🤔
Maybe it’s time to draft all this into a spec or, rather, two different specs. I might do that over the weekend.
@falsifian I think we’re talking about different ideas here. 🤔
Maybe it’s time to draft all this into a spec or, rather, two different specs. I might do that over the weekend.
@prologic Nah, just language barrier and/or me being a big stupid. 🥴 All good. 👌
@prologic Nah, just language barrier and/or me being a big stupid. 🥴 All good. 👌
@prologic Nah, just language barrier and/or me being a big stupid. 🥴 All good. 👌
@prologic Nah, just language barrier and/or me being a big stupid. 🥴 All good. 👌
@prologic Okay, looks like I misunderstood/misinterpreted your previous message then. 👌
@prologic Okay, looks like I misunderstood/misinterpreted your previous message then. 👌
@prologic Okay, looks like I misunderstood/misinterpreted your previous message then. 👌
@prologic Okay, looks like I misunderstood/misinterpreted your previous message then. 👌
@prologic So, this is either me nit-picking or me not understanding the hash system after all. 😃
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? 🤔
@prologic So, this is either me nit-picking or me not understanding the hash system after all. 😃
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? 🤔
@prologic So, this is either me nit-picking or me not understanding the hash system after all. 😃
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? 🤔
@prologic So, this is either me nit-picking or me not understanding the hash system after all. 😃
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? 🤔
One distinct disadvantage of (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.
One distinct disadvantage of (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.
One distinct disadvantage of (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.
One distinct disadvantage of (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.
Held another “talk” about Git today at work. It was covering some “basics” about what’s going on in the .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. 👌
Held another “talk” about Git today at work. It was covering some “basics” about what’s going on in the .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. 👌
Held another “talk” about Git today at work. It was covering some “basics” about what’s going on in the .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. 👌
Held another “talk” about Git today at work. It was covering some “basics” about what’s going on in the .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. 👌
@lyse I’m gonna do some self-tests on face blindness. 😂
@lyse I’m gonna do some self-tests on face blindness. 😂
@lyse I’m gonna do some self-tests on face blindness. 😂
@lyse I’m gonna do some self-tests on face blindness. 😂
@lyse
> 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.
@lyse
> 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.
@lyse
> 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.
@lyse
> 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.
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd222) Hello Birds!]
Latest edit wins:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd222) Hello Birds!]
Latest edit wins:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
\n \n \n
\n \n [(edit:#abcd111) Hello World!]
\n \n [(edit:#abcd222) Hello Birds!]
Latest edit wins:
\n \n \n
\n \n [(edit:#abcd111) Hello World!]
\n \n [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd222) Hello Birds!]
Latest edit wins:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
What about edits of edits? Do we want to “chain” edits or does the latest edit simply win?
Chained edits:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd222) Hello Birds!]
Latest edit wins:
[#abcd111] [2024-09-20T12:00:00Z] [Hello!]
[#abcd222] [2024-09-20T12:10:00Z] [(edit:#abcd111) Hello World!]
[#abcd333] [2024-09-20T12:20:00Z] [(edit:#abcd111) Hello Birds!]
Does the first version have any benefits? I don’t think so … ?
@prologic Yeah, you’re right. That’s an implementation detail of jenny. Right now, the order of twts doesn’t matter at all, because it’s only relevant at display time – and that’s the job of mutt. 😅
@prologic Yeah, you’re right. That’s an implementation detail of jenny. Right now, the order of twts doesn’t matter at all, because it’s only relevant at display time – and that’s the job of mutt. 😅
@prologic Yeah, you’re right. That’s an implementation detail of jenny. Right now, the order of twts doesn’t matter at all, because it’s only relevant at display time – and that’s the job of mutt. 😅
@prologic Yeah, you’re right. That’s an implementation detail of jenny. Right now, the order of twts doesn’t matter at all, because it’s only relevant at display time – and that’s the job of mutt. 😅
@falsifian Oof, yeah, I haven’t even started thinking about supporting two schemes at the same time. 😅 I’d be hoping for *not* having to use something like an sqlite database, if it can’t be avoided.
By the way: Since we have so few modern twtxt/Yarn clients, forking jenny might not be the worst idea. *If* you wanted to take it into a very different direction, then by all means, go for it. 👍
@falsifian Oof, yeah, I haven’t even started thinking about supporting two schemes at the same time. 😅 I’d be hoping for *not* having to use something like an sqlite database, if it can’t be avoided.
By the way: Since we have so few modern twtxt/Yarn clients, forking jenny might not be the worst idea. *If* you wanted to take it into a very different direction, then by all means, go for it. 👍
@falsifian Oof, yeah, I haven’t even started thinking about supporting two schemes at the same time. 😅 I’d be hoping for *not* having to use something like an sqlite database, if it can’t be avoided.
By the way: Since we have so few modern twtxt/Yarn clients, forking jenny might not be the worst idea. *If* you wanted to take it into a very different direction, then by all means, go for it. 👍
@falsifian Oof, yeah, I haven’t even started thinking about supporting two schemes at the same time. 😅 I’d be hoping for *not* having to use something like an sqlite database, if it can’t be avoided.
By the way: Since we have so few modern twtxt/Yarn clients, forking jenny might not be the worst idea. *If* you wanted to take it into a very different direction, then by all means, go for it. 👍
@lyse When it asks a Yarn pod, you mean? Yeah, it does so implicitly. It builds a tiny dummy feed from the JSON response and then looks for the specified twt hash in that feed.
@lyse When it asks a Yarn pod, you mean? Yeah, it does so implicitly. It builds a tiny dummy feed from the JSON response and then looks for the specified twt hash in that feed.
@lyse When it asks a Yarn pod, you mean? Yeah, it does so implicitly. It builds a tiny dummy feed from the JSON response and then looks for the specified twt hash in that feed.
@lyse When it asks a Yarn pod, you mean? Yeah, it does so implicitly. It builds a tiny dummy feed from the JSON response and then looks for the specified twt hash in that feed.
@prologic Wouldn’t work in what way? Could you elaborate? 🤔
Do you consider crawling archived feeds a problem/failure? 🤔
@prologic Wouldn’t work in what way? Could you elaborate? 🤔
Do you consider crawling archived feeds a problem/failure? 🤔
@prologic Wouldn’t work in what way? Could you elaborate? 🤔
Do you consider crawling archived feeds a problem/failure? 🤔
@prologic Wouldn’t work in what way? Could you elaborate? 🤔
Do you consider crawling archived feeds a problem/failure? 🤔
@david Such a funny picture – we’ve been to Florida once some ~30 years ago and it looked almost *exactly* like that. 😅~
@david Such a funny picture – we’ve been to Florida once some ~30 years ago and it looked almost *exactly* like that. 😅~
@david Such a funny picture – we’ve been to Florida once some ~30 years ago and it looked almost *exactly* like that. 😅~
@david Such a funny picture – we’ve been to Florida once some ~30 years ago and it looked almost *exactly* like that. 😅~
@david Yeah, but it happened so fast with him. 😅 I remember watching some of his talks 1-3 years ago, looked completely different, I think. 😅
Luckily I can still recognize the voice, so I know it’s him, lol.
@david Yeah, but it happened so fast with him. 😅 I remember watching some of his talks 1-3 years ago, looked completely different, I think. 😅
Luckily I can still recognize the voice, so I know it’s him, lol.
@david Yeah, but it happened so fast with him. 😅 I remember watching some of his talks 1-3 years ago, looked completely different, I think. 😅
Luckily I can still recognize the voice, so I know it’s him, lol.