# 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 17
# self = https://watcher.sour.is/conv/mhtocjq
@bender Yes, they do π€£ Implicitly, or threading would never work at all π
Nor lookups π€£ They are used as keys. Think of them like a primary key in a database or index. I totally get where you're coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (_like we do_) and I believe we would just encounter other problems by doing so.
My money is on extending the Twt Subject extension to support more (_optional_) advanced "subjects"; i.e: indicating you edited a Twt you already published in your feed as @falsifian indicated π
Then we have a secondary (_bure much rarer_) problem of the "identity" of a feed in the first place. Using the URL you fetch the feed from as @lyse 's client tt seems to do or using the # url = metadata field as every other client does (_according to the spec_) is problematic when you decide to change where you host your feed. In fact the spec says:
> Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.
See Choosing the Feed URL -- This is one of our longest debates and challenges, and I _think_ (_I suspect along with @xuu _) that the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes.
@bender Yes, they do π€£ Implicitly, or threading would never work at all π
Nor lookups π€£ They are used as keys. Think of them like a primary key in a database or index. I totally get where you're coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (_like we do_) and I believe we would just encounter other problems by doing so.
My money is on extending the Twt Subject extension to support more (_optional_) advanced "subjects"; i.e: indicating you edited a Twt you already published in your feed as @falsifian indicated π
Then we have a secondary (_bure much rarer_) problem of the "identity" of a feed in the first place. Using the URL you fetch the feed from as @lyse 's client tt seems to do or using the # url = metadata field as every other client does (_according to the spec_) is problematic when you decide to change where you host your feed. In fact the spec says:
> Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.
See Choosing the Feed URL -- This is one of our longest debates and challenges, and I _think_ (_I suspect along with @xuu _) that the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes.
@prologic
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? π€
@prologic
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? π€
@prologic
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? π€
@prologic
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? π€
@prologic Oh, wait, thereβs already another thread about it. π
@prologic Oh, wait, thereβs already another thread about it. π
@prologic Oh, wait, thereβs already another thread about it. π
@prologic Oh, wait, thereβs already another thread about it. π
> the right way to solve this is to use public/private key(s) where you actually have a public key fingerprint as your feedβs unique identity that never changes.
i would rather it be a random value signed by a key. That way the key can change but the value stays the same.
Key rotation is a very important feature in a system like this.
@xuu it's not really strictly required if we're just talking about identity though right? If we're talking about encryption then yes I agree rotate and keys becomes very important if you want to have attributes like perfect forward secrecy.
@xuu it's not really strictly required if we're just talking about identity though right? If we're talking about encryption then yes I agree rotate and keys becomes very important if you want to have attributes like perfect forward secrecy.
@prologic a signature *IS* encryption in reverse. If my private key becomes compromised then they can impersonate me. Being able to manage promotion and revocation of keys needed even in a system where its used for just signatures.
@xuu True π
I guess it comes down to our risk appetite and the attack vectors we're trying to solve for π€
@xuu True π
I guess it comes down to our risk appetite and the attack vectors we're trying to solve for π€