> 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...