# 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 31
# self = https://watcher.sour.is/conv/crmwgxq
movq
www.uninformativ.de
View Thread
Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

- 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! 😊
movq
www.uninformativ.de
View Thread
Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

- 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! 😊
movq
www.uninformativ.de
View Thread
Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

- 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! 😊
movq
www.uninformativ.de
View Thread
Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

- 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! 😊
bender
twtxt.net
View Thread
@movq good job!
prologic
twtxt.net
View Thread
@movq I just saw thes come through! 🙏 Thank you very much, I'll definitely have a read tomorrow! 👌
prologic
twtxt.net
View Thread
@movq I just saw thes come through! 🙏 Thank you very much, I'll definitely have a read tomorrow! 👌
prologic
twtxt.net
View Thread
I just read the primary spec I'm strongly in support of and it's pretty rock solid for me 👌 💯
prologic
twtxt.net
View Thread
I just read the primary spec I'm strongly in support of and it's pretty rock solid for me 👌 💯
movq
www.uninformativ.de
View Thread
Guess you could say:

- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
movq
www.uninformativ.de
View Thread
Guess you could say:

- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
movq
www.uninformativ.de
View Thread
Guess you could say:

- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
movq
www.uninformativ.de
View Thread
Guess you could say:

- (replyto:…) is twtxt-style
- (edit:…) and (delete:…) is Yarn-style
movq
www.uninformativ.de
View Thread
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.
movq
www.uninformativ.de
View Thread
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.
movq
www.uninformativ.de
View Thread
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.
movq
www.uninformativ.de
View Thread
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.
movq
www.uninformativ.de
View Thread
Alright, let’s call attention to this fact and let’s hear your opinions on this:

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? 🤔
movq
www.uninformativ.de
View Thread
Alright, let’s call attention to this fact and let’s hear your opinions on this:

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? 🤔
movq
www.uninformativ.de
View Thread
Alright, let’s call attention to this fact and let’s hear your opinions on this:

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? 🤔
movq
www.uninformativ.de
View Thread
Alright, let’s call attention to this fact and let’s hear your opinions on this:

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? 🤔
lyse
lyse.isobeef.org
View Thread
@movq Awesome, thank you very much! I'll have a look at it tomorrow.
sorenpeter
darch.dk
View Thread
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
sorenpeter
darch.dk
View Thread
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
sorenpeter
darch.dk
View Thread
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
sorenpeter
darch.dk
View Thread
Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?
movq
www.uninformativ.de
View Thread
@sorenpeter No, we don’t need both. They are competing proposals and only one of them should get merged. 😃 The format (#<DATETIME URL>) would also work, yeah.
movq
www.uninformativ.de
View Thread
@sorenpeter No, we don’t need both. They are competing proposals and only one of them should get merged. 😃 The format (#<DATETIME URL>) would also work, yeah.
movq
www.uninformativ.de
View Thread
@sorenpeter No, we don’t need both. They are competing proposals and only one of them should get merged. 😃 The format (#<DATETIME URL>) would also work, yeah.
movq
www.uninformativ.de
View Thread
@sorenpeter No, we don’t need both. They are competing proposals and only one of them should get merged. 😃 The format (#<DATETIME URL>) would also work, yeah.
lyse
lyse.isobeef.org
View Thread
Thanks again for typing it up, @movq! I left a few comments there. Currently, I'm in favor of the location-based adressing, that's heaps simpler.