# 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 37
# self = https://watcher.sour.is/conv/mkwtgrq
π Thanks for joining us on our Sept monthly Yarn.social meetup today y'all πββοΈ We had @david @sorenpeter @doesnm @falsifian and @xuu πͺ Nice turn out! (_not all at once of course, as we normally run this over 4 hours as we span many time zones!_)
Things we talked about:
- Decentralised vs. Distributed
- Use of SHA256 for Twt Hash(es)
- We solved Edits! π₯³
- UUID(s) probably won't work! (_susceptible to sppofing_)
- Helped @sorenpeter write some PHP to process/parse User-Agent and service his feed via a custom PHP script π
- @falsifian introduced himself π
- Talked about Merkle Trees π³
Did I miss anything? π€
π Thanks for joining us on our Sept monthly Yarn.social meetup today y'all πββοΈ We had @david @sorenpeter @doesnm @falsifian and @xuu πͺ Nice turn out! (_not all at once of course, as we normally run this over 4 hours as we span many time zones!_)
Things we talked about:
- Decentralised vs. Distributed
- Use of SHA256 for Twt Hash(es)
- We solved Edits! π₯³
- UUID(s) probably won't work! (_susceptible to sppofing_)
- Helped @sorenpeter write some PHP to process/parse User-Agent and service his feed via a custom PHP script π
- @falsifian introduced himself π
- Talked about Merkle Trees π³
Did I miss anything? π€
Lol, im just join for several minutes. Wait, Merkle Trees in twtxt?
@prologic Any more details on the edit stuff? π€
@prologic Any more details on the edit stuff? π€
@prologic Any more details on the edit stuff? π€
@prologic Any more details on the edit stuff? π€
@movq Yes! Basically @david points out that if we mandate that authors should retain the original timestamp in their feed when adjusting content, making fixes, etc, that they retain the original timestamp and leave it unaltered. We already do this anyway, we just need to say so.
Now we have a situation where folks participating in a "conversation" (thread) with appropriate clients can automatically detect edits with almost 100% accuracy by mere fact that the next time they fetch a feed that contains an edit, they now see two versions of the Twt with two different hashes, but identical timestamps.
You can use the fetch time to approximate a "version number" and deal with the display (UX) appropriately.
I can't believe I didn't think of this before π€¦ββοΈ
@movq Yes! Basically @david points out that if we mandate that authors should retain the original timestamp in their feed when adjusting content, making fixes, etc, that they retain the original timestamp and leave it unaltered. We already do this anyway, we just need to say so.
Now we have a situation where folks participating in a "conversation" (thread) with appropriate clients can automatically detect edits with almost 100% accuracy by mere fact that the next time they fetch a feed that contains an edit, they now see two versions of the Twt with two different hashes, but identical timestamps.
You can use the fetch time to approximate a "version number" and deal with the display (UX) appropriately.
I can't believe I didn't think of this before π€¦ββοΈ
@prologic Okay. So it goes like this:
My client fetches a feed. It builds a map/hashmap/dictionary of all twts: Timestamps map to twt hashes. It then stores/shows the twts. It also stores the hashmap.
On the next fetch operation, the client re-processes all twts in the feed. It must now compare each timestamp to the previously built hashmap: Aha, timestamp T has now a twt hash of B instead of A, so this is an edited twt.
Did I understand that correctly so far? π€
@prologic Okay. So it goes like this:
My client fetches a feed. It builds a map/hashmap/dictionary of all twts: Timestamps map to twt hashes. It then stores/shows the twts. It also stores the hashmap.
On the next fetch operation, the client re-processes all twts in the feed. It must now compare each timestamp to the previously built hashmap: Aha, timestamp T has now a twt hash of B instead of A, so this is an edited twt.
Did I understand that correctly so far? π€
@prologic Okay. So it goes like this:
My client fetches a feed. It builds a map/hashmap/dictionary of all twts: Timestamps map to twt hashes. It then stores/shows the twts. It also stores the hashmap.
On the next fetch operation, the client re-processes all twts in the feed. It must now compare each timestamp to the previously built hashmap: Aha, timestamp T has now a twt hash of B instead of A, so this is an edited twt.
Did I understand that correctly so far? π€
@prologic Okay. So it goes like this:
My client fetches a feed. It builds a map/hashmap/dictionary of all twts: Timestamps map to twt hashes. It then stores/shows the twts. It also stores the hashmap.
On the next fetch operation, the client re-processes all twts in the feed. It must now compare each timestamp to the previously built hashmap: Aha, timestamp T has now a twt hash of B instead of A, so this is an edited twt.
Did I understand that correctly so far? π€
@prologic I'm afraid, I don't understand how the edit detection works so that it does not break threads. All I see is that some hash in a subject is missing.
@lyse See @movq 's undersanding. Now this had some edge cases that we agreed probably aren't worth solving for.
@lyse See @movq 's undersanding. Now this had some edge cases that we agreed probably aren't worth solving for.
@prologic So this hinges on clients keeping a history of the twt hashes. Clients that clean their cache or simply start following a feed later on have no way of reconstructing older twt hash versions and thus no way of reconstructing existing threads. Right?
@prologic So this hinges on clients keeping a history of the twt hashes. Clients that clean their cache or simply start following a feed later on have no way of reconstructing older twt hash versions and thus no way of reconstructing existing threads. Right?
@prologic So this hinges on clients keeping a history of the twt hashes. Clients that clean their cache or simply start following a feed later on have no way of reconstructing older twt hash versions and thus no way of reconstructing existing threads. Right?
@prologic So this hinges on clients keeping a history of the twt hashes. Clients that clean their cache or simply start following a feed later on have no way of reconstructing older twt hash versions and thus no way of reconstructing existing threads. Right?
It's no worse than what we have now, it's better. But yes caveats still apply.
It's no worse than what we have now, it's better. But yes caveats still apply.
Personally I don't see it as a problem. I didn't even really see edits as a problem either tbh, but this is just an incremental improvement I think.
Personally I don't see it as a problem. I didn't even really see edits as a problem either tbh, but this is just an incremental improvement I think.
@prologic If I understand correctly, then this means that twt hashes no longer uniquely refer to one specific twt. When someone talks about #1234567, it could refer to the original or some edit of it. It is up to clients to find out what this hash could mean (by keeping a historical database of all feed versions, basically).
Isnβt this *essentially* the same as only including url and timestamp in the hash?
@prologic If I understand correctly, then this means that twt hashes no longer uniquely refer to one specific twt. When someone talks about #1234567, it could refer to the original or some edit of it. It is up to clients to find out what this hash could mean (by keeping a historical database of all feed versions, basically).
Isnβt this *essentially* the same as only including url and timestamp in the hash?
@prologic If I understand correctly, then this means that twt hashes no longer uniquely refer to one specific twt. When someone talks about #1234567, it could refer to the original or some edit of it. It is up to clients to find out what this hash could mean (by keeping a historical database of all feed versions, basically).
Isnβt this *essentially* the same as only including url and timestamp in the hash?
@prologic If I understand correctly, then this means that twt hashes no longer uniquely refer to one specific twt. When someone talks about #1234567, it could refer to the original or some edit of it. It is up to clients to find out what this hash could mean (by keeping a historical database of all feed versions, basically).
Isnβt this *essentially* the same as only including url and timestamp in the hash?
@movq Hmmm π€ Intuitively I say "No they're not the same"; but let me sleep on it ππ΄
@movq Hmmm π€ Intuitively I say "No they're not the same"; but let me sleep on it ππ΄
@prologic That can only work if I happen to have the original one as well. But what are the odds for that? Quite low I'd say. It's rare that I see a once working thread to be cactus later on. Usually, when I arrive, police already broke up the party. Yarnd might be more lucky in that it constantly pulls, but I don't.
Anyway, I won't implement that in my client. Sounds too much effort for the tiny gain.
@lyse Maybe you're right: Let's pause this while edit/delete discussions.
@lyse Maybe you're right: Let's pause this while edit/delete discussions.