> Gee I wish my car would listen to my in-car conversations and serve me ads.
π€¬π€¦ββοΈ #Ford #Ads
> Gee I wish my car would listen to my in-car conversations and serve me ads.
π€¬π€¦ββοΈ #Ford #Ads
The question is how much time do we give ourselves as we're all a bit time poor and I can't imagine we would do this quickly.
The question is how much time do we give ourselves as we're all a bit time poor and I can't imagine we would do this quickly.
ssh and ssh-keygen utilities. No reason really.
ssh and ssh-keygen utilities. No reason really.
$ echo 'hello world' | ./salty -i ./test_ed25519 --ssh-key --sign
$ echo 'hello world' | ./salty -i ./test_ed25519 --ssh-key --sign
$ echo 'hello world' | ./salty -i ./test.key -s | ./salty -i ./test.key -v
# signed by: kex1yfzzthmsdlqhgwzafy9zpjze6a0asxf6y552dp4yhvq66a4jje0qxqapvd
hello world
$ echo 'hello world' | ./salty -i ./test.key -s | ./salty -i ./test.key -v
# signed by: kex1yfzzthmsdlqhgwzafy9zpjze6a0asxf6y552dp4yhvq66a4jje0qxqapvd
hello world
> Are SSH signatures standardized and are there robust software libraries that can handle them? Weβll need a library in at least Python and Go to provide verified feed support with the currently used clients.
We already have this. Ed25519 libraries exist for all major languages. Aside from using
ssh-keygen -Y sign and ssh-keygen -Y verify, you can also use the salty CLI itself (https://git.mills.io/prologic/salty), and I'm sure there are other command-line tools that _could_ be used too.> If we all implemented this, every twt hash would suddenly change and every conversation thread weβve ever had would at least lose its opening post.
Yes. This would happen, so we'd have to make a decision around this, either a) a cut-off point or b) some way to progressively transition.
> Are SSH signatures standardized and are there robust software libraries that can handle them? Weβll need a library in at least Python and Go to provide verified feed support with the currently used clients.
We already have this. Ed25519 libraries exist for all major languages. Aside from using
ssh-keygen -Y sign and ssh-keygen -Y verify, you can also use the salty CLI itself (https://git.mills.io/prologic/salty), and I'm sure there are other command-line tools that _could_ be used too.> If we all implemented this, every twt hash would suddenly change and every conversation thread weβve ever had would at least lose its opening post.
Yes. This would happen, so we'd have to make a decision around this, either a) a cut-off point or b) some way to progressively transition.
Sharing hosting is also the reason why you can't just use part of a URL really.
Sharing hosting is also the reason why you can't just use part of a URL really.
1. Generate a Private/Public ED25519 key pair
2. Use this key pair to sign your Twtxt feed
3. Use it as your feed's identity in place of
# url = as # key = ...For example:
e
$ ssh-keygen -f prologic@twtxt.net
$ ssh-keygen -Y sign -n prologic@twtxt.net -f prologic@twtxt.net twtxt.txt
And your feed would looke like:
# nick = prologic
# key = SHA256:23OiSfuPC4zT0lVh1Y+XKh+KjP59brhZfxFHIYZkbZs
# sig = twtxt.txt.sig
# prev = j6bmlgq twtxt.txt/1
# avatar = https://twtxt.net/user/prologic/avatar#gdoicerjkh3nynyxnxawwwkearr4qllkoevtwb3req4hojx5z43q
# description = "Problems are Solved by Method" π¦πΊπ¨βπ»π¨βπ¦―πΉβ πβ― π¨βπ©βπ§βπ§π₯ -- James Mills (operator of twtxt.net / creator of Yarn.social π§Ά)
2024-06-14T18:22:17Z (#nef6byq) @<bender https://twtxt.net/user/bender/twtxt.txt> Hehe thanks! π
Still gotta sort out some other bugs, but that's tomorrows job π€
...
Twt Hash extension would change of course to use a feed's ED25519 public key fingerprint.
1. Generate a Private/Public ED25519 key pair
2. Use this key pair to sign your Twtxt feed
3. Use it as your feed's identity in place of
# url = as # key = ...For example:
e
$ ssh-keygen -f prologic@twtxt.net
$ ssh-keygen -Y sign -n prologic@twtxt.net -f prologic@twtxt.net twtxt.txt
And your feed would looke like:
# nick = prologic
# key = SHA256:23OiSfuPC4zT0lVh1Y+XKh+KjP59brhZfxFHIYZkbZs
# sig = twtxt.txt.sig
# prev = j6bmlgq twtxt.txt/1
# avatar = https://twtxt.net/user/prologic/avatar#gdoicerjkh3nynyxnxawwwkearr4qllkoevtwb3req4hojx5z43q
# description = "Problems are Solved by Method" π¦πΊπ¨βπ»π¨βπ¦―πΉβ πβ― π¨βπ©βπ§βπ§π₯ -- James Mills (operator of twtxt.net / creator of Yarn.social π§Ά)
2024-06-14T18:22:17Z\t(#nef6byq) @<bender https://twtxt.net/user/bender/twtxt.txt> Hehe thanks! π
Still gotta sort out some other bugs, but that's tomorrows job π€
...
Twt Hash extension would change of course to use a feed's ED25519 public key fingerprint.
1. Generate a Private/Public ED25519 key pair
2. Use this key pair to sign your Twtxt feed
3. Use it as your feed's identity in place of
# url = as # key = ...For example:
e
$ ssh-keygen -f prologic@twtxt.net
$ ssh-keygen -Y sign -n prologic@twtxt.net -f prologic@twtxt.net twtxt.txt
And your feed would looke like:
# nick = prologic
# key = SHA256:23OiSfuPC4zT0lVh1Y+XKh+KjP59brhZfxFHIYZkbZs
# sig = twtxt.txt.sig
# prev = j6bmlgq twtxt.txt/1
# avatar = https://twtxt.net/user/prologic/avatar#gdoicerjkh3nynyxnxawwwkearr4qllkoevtwb3req4hojx5z43q
# description = "Problems are Solved by Method" π¦πΊπ¨βπ»π¨βπ¦―πΉβ πβ― π¨βπ©βπ§βπ§π₯ -- James Mills (operator of twtxt.net / creator of Yarn.social π§Ά)
2024-06-14T18:22:17Z (#nef6byq) @<bender https://twtxt.net/user/bender/twtxt.txt> Hehe thanks! π
Still gotta sort out some other bugs, but that's tomorrows job π€
...
Twt Hash extension would change of course to use a feed's ED25519 public key fingerprint.
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.
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.
yarnd (_which I'd love to turn into a C library that others can just import_) can do some interesting things here. @xuu can probably talk more on this...
yarnd (_which I'd love to turn into a C library that others can just import_) can do some interesting things here. @xuu can probably talk more on this...
Message-Id. Email is a federated system, but by no means is it "decentralised". You still have to send your email somewhere, not just post it on a website on your own server like Twtxt π
There are some subtitles differences like this that makes Message/Thread Id(s) not really that suitable IMO.
Message-Id. Email is a federated system, but by no means is it "decentralised". You still have to send your email somewhere, not just post it on a website on your own server like Twtxt π
There are some subtitles differences like this that makes Message/Thread Id(s) not really that suitable IMO.
- How do you come up with the message/thread id in the first place? I'm pretty sure most clients just use a UUID.
- How do you know what you're replying to if you don't see the message/thread id in the first place?
- How do two different users that don't know each other, but follow the same feed (say /.) make two independent responses forming a thread? What message/thread id do they use? (see above)
- How do you come up with the message/thread id in the first place? I'm pretty sure most clients just use a UUID.
- How do you know what you're replying to if you don't see the message/thread id in the first place?
- How do two different users that don't know each other, but follow the same feed (say /.) make two independent responses forming a thread? What message/thread id do they use? (see above)
> I donβt think twtxt hashes are long enough to prevent spoofing.
The current spec needs to be updated to expand the hash length to 11 characters to avoid hash collisions (_which will happen at some point with 7, if not already_).
The issue isn't dealing with "spoofing", it's about solving how clients in a decentralised model agree on the threading model and identity of a thread. Message ID(s) suffer from the fact that as @movq points out, clients have to "obey" this unwritten rule, but they're otherwise just arbitrary. Whereas Twt Hashes (_I didn't come up with the idea originally, some smart fellow in cryptography did_) are content addressable, meaning that clients don't have to agree on anything, they can trust that the hash is a cryptographic representing of the thread they're replying to, no matter what.
> I donβt think twtxt hashes are long enough to prevent spoofing.
The current spec needs to be updated to expand the hash length to 11 characters to avoid hash collisions (_which will happen at some point with 7, if not already_).
The issue isn't dealing with "spoofing", it's about solving how clients in a decentralised model agree on the threading model and identity of a thread. Message ID(s) suffer from the fact that as @movq points out, clients have to "obey" this unwritten rule, but they're otherwise just arbitrary. Whereas Twt Hashes (_I didn't come up with the idea originally, some smart fellow in cryptography did_) are content addressable, meaning that clients don't have to agree on anything, they can trust that the hash is a cryptographic representing of the thread they're replying to, no matter what.
> I donβt know what happened behind the scenes that killed off twtxt (I have a few guesses, though), but the sad truth is that itβs gone.