# 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 8
# self = https://watcher.sour.is/conv/ff2lzqq
bender
twtxt.net
View Thread
@prologic what if I copy your uuid, and use it on my feed? What happens then? Also, was the dot after the timestamp intended?
prologic
twtxt.net
View Thread
@bender This is sadly where you need two things:

- A /twtxt.txt.sig (_detached signauture_)
- Or a way to sign the # uuid = with a key that can be verified.

Hmmm and as I write this actually, I _think_ this doesn't work either, because you can still just copy it regardless. Hmmm @xuu help me out here? How do we prevent "spoofing"? 🤔
prologic
twtxt.net
View Thread
@bender This is sadly where you need two things:

- A /twtxt.txt.sig (_detached signauture_)
- Or a way to sign the # uuid = with a key that can be verified.

Hmmm and as I write this actually, I _think_ this doesn't work either, because you can still just copy it regardless. Hmmm @xuu help me out here? How do we prevent "spoofing"? 🤔
prologic
twtxt.net
View Thread
I think the only legit way of preventing this kind of "spoofing attack" would be:

> Digitally Sign Twts: Each Twt could be digitally signed using a private key associated with the UUID. The signature would be calculated over the concatenation of the UUID, timestamp, and content. The public key could be published along with the feed so anyone can verify the authenticity of the Twt by checking the signature. This approach ensures that only the true owner of the UUID (and the corresponding private key) can produce valid hashes.

Which leads us to more Cryptography. Something which y'all voted against.
prologic
twtxt.net
View Thread
I think the only legit way of preventing this kind of "spoofing attack" would be:

> Digitally Sign Twts: Each Twt could be digitally signed using a private key associated with the UUID. The signature would be calculated over the concatenation of the UUID, timestamp, and content. The public key could be published along with the feed so anyone can verify the authenticity of the Twt by checking the signature. This approach ensures that only the true owner of the UUID (and the corresponding private key) can produce valid hashes.

Which leads us to more Cryptography. Something which y'all voted against.
prologic
twtxt.net
View Thread
If we want this though (_or some of us do_) I will probably have to make the hard decision here to just fork from Twtxt entirely and define a completely new spec. If we care about the UX we need a few properties (_some of which we have, some of which we don't have and some of which are "weak"_):

- Authenticity
- Integrity
- Precision Versioning

The last one involves _actually_ supporting the notion of "Edits" and "Deletes" IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is "Versioned Twts".
prologic
twtxt.net
View Thread
If we want this though (_or some of us do_) I will probably have to make the hard decision here to just fork from Twtxt entirely and define a completely new spec. If we care about the UX we need a few properties (_some of which we have, some of which we don't have and some of which are "weak"_):

- Authenticity
- Integrity
- Precision Versioning

The last one involves _actually_ supporting the notion of "Edits" and "Deletes" IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is "Versioned Twts".
prologic
twtxt.net
View Thread
If we want this though (_or some of us do_) I will probably have to make the hard decision here to just fork from Twtxt entirely and define a completely new spec. If we care about the UX we need a few properties (_some of which we have, some of which we don't have and some of which are "weak"_):

- Authenticity
- Integrity
- Precision

The last one involves _actually_ supporting the notion of "Edits" and "Deletes" IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is "Versioned Twts".