# 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 15565
# self = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=12606
# next = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=12706
# prev = https://watcher.sour.is?uri=https://www.uninformativ.de/twtxt.txt&offset=12506
@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.
@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.
@lyse The hash/thread-id would be shorter, but you’d lose two other benefits of (replyto:…):
1. You need a special client again to compute hashes.
2. The original feed URL is no longer visible, thus you might need to ask a Yarn pod occasionally for missing twts (I do that surprisingly often, now that I’ve implemented it) – but now you’ve lost the guarantee that Yarn gives you the correct information, because you can no longer verify it.
@lyse The hash/thread-id would be shorter, but you’d lose two other benefits of (replyto:…):
1. You need a special client again to compute hashes.
2. The original feed URL is no longer visible, thus you might need to ask a Yarn pod occasionally for missing twts (I do that surprisingly often, now that I’ve implemented it) – but now you’ve lost the guarantee that Yarn gives you the correct information, because you can no longer verify it.
@lyse The hash/thread-id would be shorter, but you’d lose two other benefits of (replyto:…):
1. You need a special client again to compute hashes.
2. The original feed URL is no longer visible, thus you might need to ask a Yarn pod occasionally for missing twts (I do that surprisingly often, now that I’ve implemented it) – but now you’ve lost the guarantee that Yarn gives you the correct information, because you can no longer verify it.
@lyse The hash/thread-id would be shorter, but you’d lose two other benefits of (replyto:…):
1. You need a special client again to compute hashes.
2. The original feed URL is no longer visible, thus you might need to ask a Yarn pod occasionally for missing twts (I do that surprisingly often, now that I’ve implemented it) – but now you’ve lost the guarantee that Yarn gives you the correct information, because you can no longer verify it.
@lyse Right, feed rotation gets ugly. We’d have (replyto:example.com/tw.txt,$timestamp) but maybe that feed doesn’t actually contain that stamp, so you have to got further back … but you should NOT reference an archived feed in your (replyto:…) thingy, it should still be the “main feed URL” (because the contents of archived feeds aren’t stable, see @prologic’s feeds for example). That’s not too great.
Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
@lyse Right, feed rotation gets ugly. We’d have (replyto:example.com/tw.txt,$timestamp) but maybe that feed doesn’t actually contain that stamp, so you have to got further back … but you should NOT reference an archived feed in your (replyto:…) thingy, it should still be the “main feed URL” (because the contents of archived feeds aren’t stable, see @prologic’s feeds for example). That’s not too great.
Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
@lyse Right, feed rotation gets ugly. We’d have (replyto:example.com/tw.txt,$timestamp) but maybe that feed doesn’t actually contain that stamp, so you have to got further back … but you should NOT reference an archived feed in your (replyto:…) thingy, it should still be the “main feed URL” (because the contents of archived feeds aren’t stable, see @prologic’s feeds for example). That’s not too great.
Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
@lyse Right, feed rotation gets ugly. We’d have (replyto:example.com/tw.txt,$timestamp) but maybe that feed doesn’t actually contain that stamp, so you have to got further back … but you should NOT reference an archived feed in your (replyto:…) thingy, it should still be the “main feed URL” (because the contents of archived feeds aren’t stable, see @prologic’s feeds for example). That’s not too great.
Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
… then, of course, I wouldn’t *need* to ask a Yarn pod for a certain twt if we used (replyto:…) instead of (#123467), because the original source of the twt is no longer obscured by a hash value and I can just pull the original feed. Asking a Yarn pod is only interesting at the moment because I have no idea where to get (#123467) from.
Only when the original feed has gone offline will querying a Yarn pod become relevant again.
I have to admit here that some of the goals/philosophy of Yarn simply don’t apply to my use cases. 😅 I don’t run a daemon that speaks a gossipping protocol with neighboring pods or stuff like that. I think I don’t have a hard time accepting that feeds might go offline in two months, so be it. Digging up ancient twts from some sort of globally distributed file system isn’t one of my goals. It’s a completely different thing for me. Hmmm. 🤔
… then, of course, I wouldn’t *need* to ask a Yarn pod for a certain twt if we used (replyto:…) instead of (#123467), because the original source of the twt is no longer obscured by a hash value and I can just pull the original feed. Asking a Yarn pod is only interesting at the moment because I have no idea where to get (#123467) from.
Only when the original feed has gone offline will querying a Yarn pod become relevant again.
I have to admit here that some of the goals/philosophy of Yarn simply don’t apply to my use cases. 😅 I don’t run a daemon that speaks a gossipping protocol with neighboring pods or stuff like that. I think I don’t have a hard time accepting that feeds might go offline in two months, so be it. Digging up ancient twts from some sort of globally distributed file system isn’t one of my goals. It’s a completely different thing for me. Hmmm. 🤔
… then, of course, I wouldn’t *need* to ask a Yarn pod for a certain twt if we used (replyto:…) instead of (#123467), because the original source of the twt is no longer obscured by a hash value and I can just pull the original feed. Asking a Yarn pod is only interesting at the moment because I have no idea where to get (#123467) from.
Only when the original feed has gone offline will querying a Yarn pod become relevant again.
I have to admit here that some of the goals/philosophy of Yarn simply don’t apply to my use cases. 😅 I don’t run a daemon that speaks a gossipping protocol with neighboring pods or stuff like that. I think I don’t have a hard time accepting that feeds might go offline in two months, so be it. Digging up ancient twts from some sort of globally distributed file system isn’t one of my goals. It’s a completely different thing for me. Hmmm. 🤔
… then, of course, I wouldn’t *need* to ask a Yarn pod for a certain twt if we used (replyto:…) instead of (#123467), because the original source of the twt is no longer obscured by a hash value and I can just pull the original feed. Asking a Yarn pod is only interesting at the moment because I have no idea where to get (#123467) from.
Only when the original feed has gone offline will querying a Yarn pod become relevant again.
I have to admit here that some of the goals/philosophy of Yarn simply don’t apply to my use cases. 😅 I don’t run a daemon that speaks a gossipping protocol with neighboring pods or stuff like that. I think I don’t have a hard time accepting that feeds might go offline in two months, so be it. Digging up ancient twts from some sort of globally distributed file system isn’t one of my goals. It’s a completely different thing for me. Hmmm. 🤔
I’m bad with faces, I know that. But I’m having a *really* hard time recognizing Linus in this video:
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? 😳
I’m bad with faces, I know that. But I’m having a *really* hard time recognizing Linus in this video:
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? 😳
I’m bad with faces, I know that. But I’m having a *really* hard time recognizing Linus in this video:
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? 😳
I’m bad with faces, I know that. But I’m having a *really* hard time recognizing Linus in this video:
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? 😳
@david Aye, I’ve pushed some commits. (And this is *really* going to be the last non-trivial change. 😂)
@david Aye, I’ve pushed some commits. (And this is *really* going to be the last non-trivial change. 😂)
@david Aye, I’ve pushed some commits. (And this is *really* going to be the last non-trivial change. 😂)
@david Aye, I’ve pushed some commits. (And this is *really* going to be the last non-trivial change. 😂)
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t *break*, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.
@david Yeah, I was annoyed by this myself lately. twts have become *so long* nowadays, it really gets in the way.
@david Yeah, I was annoyed by this myself lately. twts have become *so long* nowadays, it really gets in the way.
@david Yeah, I was annoyed by this myself lately. twts have become *so long* nowadays, it really gets in the way.
@david Yeah, I was annoyed by this myself lately. twts have become *so long* nowadays, it really gets in the way.
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
@prologic Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be *less code*.
Implementing this whole (edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)
Do you see why I’m so reluctant to jump on this bandwagon? 😅
I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
For implementations, it would be nice if “update twts” always came *after* the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will *have to* be able to cope with any order, because feeds cannot/should not be trusted. 🫤
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
Trying to sum up the current proposal (keeping hashes):
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, “update twts”.
- A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
- A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
Right?
@prologic
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, it’s much less mysterious than that. 😅 The twt in question exists in your archived feed. It’s not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So that’s clearly an advantage of the current system.~
@prologic
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, it’s much less mysterious than that. 😅 The twt in question exists in your archived feed. It’s not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So that’s clearly an advantage of the current system.~
@prologic
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, it’s much less mysterious than that. 😅 The twt in question exists in your archived feed. It’s not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So that’s clearly an advantage of the current system.~
@prologic
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, it’s much less mysterious than that. 😅 The twt in question exists in your archived feed. It’s not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So that’s clearly an advantage of the current system.~
(Or maybe I’m talking nonsense. That’s known to happen. I’ll go to bed. 😂)
(Or maybe I’m talking nonsense. That’s known to happen. I’ll go to bed. 😂)
(Or maybe I’m talking nonsense. That’s known to happen. I’ll go to bed. 😂)
(Or maybe I’m talking nonsense. That’s known to happen. I’ll go to bed. 😂)
@quark Printing a version? I’ll think about it. 🤔
It would be easy to do for releases, but it’s a little hard to do for all the commits in between – jenny has no build process, so there’s no easy way to incorporate the output of git describe, for example.
@quark Printing a version? I’ll think about it. 🤔
It would be easy to do for releases, but it’s a little hard to do for all the commits in between – jenny has no build process, so there’s no easy way to incorporate the output of git describe, for example.
@quark Printing a version? I’ll think about it. 🤔
It would be easy to do for releases, but it’s a little hard to do for all the commits in between – jenny has no build process, so there’s no easy way to incorporate the output of git describe, for example.
@quark Printing a version? I’ll think about it. 🤔
It would be easy to do for releases, but it’s a little hard to do for all the commits in between – jenny has no build process, so there’s no easy way to incorporate the output of git describe, for example.
I’m not advocating in either direction, btw. I haven’t made up my mind yet. 😅 Just braindumping here.
The (replyto:…) proposal is definitely more in the spirit of twtxt, I’d say. It’s much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and it’s things like that that brought me to twtxt in the first place.
I’d also say that in our tiny little community, message integrity simply doesn’t matter. Signed feeds don’t matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, there’s enough “implicit trust” or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? 😅
I do have to “admit”, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the (replyto:…) proposal would work just as well in practice.
I’m not advocating in either direction, btw. I haven’t made up my mind yet. 😅 Just braindumping here.
The (replyto:…) proposal is definitely more in the spirit of twtxt, I’d say. It’s much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and it’s things like that that brought me to twtxt in the first place.
I’d also say that in our tiny little community, message integrity simply doesn’t matter. Signed feeds don’t matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, there’s enough “implicit trust” or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? 😅
I do have to “admit”, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the (replyto:…) proposal would work just as well in practice.
I’m not advocating in either direction, btw. I haven’t made up my mind yet. 😅 Just braindumping here.
The (replyto:…) proposal is definitely more in the spirit of twtxt, I’d say. It’s much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and it’s things like that that brought me to twtxt in the first place.
I’d also say that in our tiny little community, message integrity simply doesn’t matter. Signed feeds don’t matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, there’s enough “implicit trust” or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? 😅
I do have to “admit”, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the (replyto:…) proposal would work just as well in practice.
I’m not advocating in either direction, btw. I haven’t made up my mind yet. 😅 Just braindumping here.
The (replyto:…) proposal is definitely more in the spirit of twtxt, I’d say. It’s much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and it’s things like that that brought me to twtxt in the first place.
I’d also say that in our tiny little community, message integrity simply doesn’t matter. Signed feeds don’t matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, there’s enough “implicit trust” or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? 😅
I do have to “admit”, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the (replyto:…) proposal would work just as well in practice.
@falsifian @prologic @lyse
> - editing, if you don't care about message integrity
So that’s the big question, because that’s the only real difference between hashes and the (replyto:…) proposal.
Do we care about message integrity?
With (replyto:…), someone could write a twt, then I reply to it, like “you’re absolutely right!”, and then that person could change their twt to something malicious like “the earth is flat!” And then it would look like I’m a nutcase agreeing with that person. 😅
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. That’s good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isn’t message integrity ignored anyway now, at least in practice?
There’s no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does #12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we don’t want to break threads, so … what’s the point of using a hash?
@falsifian @prologic @lyse
> - editing, if you don't care about message integrity
So that’s the big question, because that’s the only real difference between hashes and the (replyto:…) proposal.
Do we care about message integrity?
With (replyto:…), someone could write a twt, then I reply to it, like “you’re absolutely right!”, and then that person could change their twt to something malicious like “the earth is flat!” And then it would look like I’m a nutcase agreeing with that person. 😅
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. That’s good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isn’t message integrity ignored anyway now, at least in practice?
There’s no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does #12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we don’t want to break threads, so … what’s the point of using a hash?
@falsifian @prologic @lyse
> - editing, if you don't care about message integrity
So that’s the big question, because that’s the only real difference between hashes and the (replyto:…) proposal.
Do we care about message integrity?
With (replyto:…), someone could write a twt, then I reply to it, like “you’re absolutely right!”, and then that person could change their twt to something malicious like “the earth is flat!” And then it would look like I’m a nutcase agreeing with that person. 😅
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. That’s good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isn’t message integrity ignored anyway now, at least in practice?
There’s no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does #12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we don’t want to break threads, so … what’s the point of using a hash?
@falsifian @prologic @lyse
> - editing, if you don't care about message integrity
So that’s the big question, because that’s the only real difference between hashes and the (replyto:…) proposal.
Do we care about message integrity?
With (replyto:…), someone could write a twt, then I reply to it, like “you’re absolutely right!”, and then that person could change their twt to something malicious like “the earth is flat!” And then it would look like I’m a nutcase agreeing with that person. 😅
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. That’s good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isn’t message integrity ignored anyway now, at least in practice?
There’s no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does #12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we don’t want to break threads, so … what’s the point of using a hash?