5 ms·

And progress has been to get there with the recent v3 of [ssb-friends](https://github.com/ssbc/ssb-friends/ https://github.com/ssbc/ssb-friends/)

by staltz 8y ago

marknadal 8y ago
I've been telling Dominic and Juan (even Feross, Mathias, etc.) that there is a simple fix for this with CRDTs (GUN's or not) since 2014 - Dominic (SSB) has been the most cutting edge, he adopted some CRDTs I think for log relay, why not also for identity? Skip to 11:45 into the video, the algorithm/cryptography for it isn't that hard either: https://www.decentralizedweb.net/videos/talk-better-algorithms-for-a-decentralized-webthe-gun-stack/ https://www.decentralizedweb.net/videos/talk-better-algorith... you could do it in SSB without needing gun!
- xj9 8y ago
  the only way to share identity in a crypto-cap system is to share privkeys, which is a big no-no. much, much safer to have multiple privkeys that are linked with signatures. you probably shouldn't think of ssb id keys as having a 1:1 relationship with a person. they are more like device keys, the person ID is a higher level construct that is expressed by publishing links that assert that a set of keys belong to the same agent.
  - ChristianBundy 8y ago
    This is similar to how it works with applications like Signal: each device has its own keypair and a person can have multiple devices. The only difference is that currently we don't have a universal way to do this, although it is in the pipeline.
    - marknadal 8y ago
      You can think of keys as being a device key. But now you just kick the can back. You still have to have an account that manages the device keys, and you certainly don't want that locked down to a device - unless that device is the user's brain. So either way, you're still gonna have to use a system to manage it that looks 110% like the MIT Open Source security/cryptography code anybody can rip from us.
      - notriddle 8y ago
        > But now you just kick the can back. You still have to have an account that manages the device keys, and you certainly don't want that locked down to a device They need to mutually confirm it. If keyA says sameAs keyB, and keyB says sameAs keyA, then they should be considered merged.
      - xj9 8y ago
        there is no account only capabilities accept this, find peace
        marknadal 8y ago
        Please don't, we need more competition in the space. If you guys do this, you'll shoot your user adoption in the foot. Do you really think XYZ millions of users moving from FB in the next decade, when they come to SSB or NAB, are going to choose the one that is intentionally more complicated/confusing/harder-to-use? Get passwords working in cryptographically secure ways and the world will be at more peace.
        xj9 8y ago
        competition implies taking different approaches. i don't think that the cap approach is inherently more confusing. the point is, there is more than one way to make a good UX on top of differing cryptographic primitives. you have one method, and that's fine, i think that capability security is a better approach so that's the path i'm taking. i don't care about millions of people. mass adoption is fine, but i don't care about the people who already have internet, smartphones, and need convincing to drop their shitty spyware android device. i care about the billions of people who are coming online in the next 5-10 years. i'm developing[0] a stack that integrates hardware, software, and p2p/mesh protocols to compete directly with telcos and OEMs. when you include hardware security, the user experience of per-device keys is much nicer. you need a passcode that is used to protect your device-entangled key and that's it. new devices pair like bluetooth, securely handshake, and publish `sameAs` depending on the type of device. users don't need to worry about anything beyond the device passcode. projects like dark crystal[1] make it easy to generate and distribute an emergency key that can be used to restore access to your devices if you forget your code. [0]: https://heropunch.io/ https://heropunch.io/ [1]: https://darkcrystal.pw/ https://darkcrystal.pw/

And progress has been to get there with the recent v3 of [ssb-friends](https://github.com/ssbc/ssb-friends/ https://github.com/ssbc/ssb-friends/)

by staltz 8y ago

And progress has been to get there with the recent v3 of [ssb-friends](https://github.com/ssbc/ssb-friends/ https://github.com/ssbc/ssb-friends/)

marknadal 8y ago

I've been telling Dominic and Juan (even Feross, Mathias, etc.) that there is a simple fix for this with CRDTs (GUN's or not) since 2014 - Dominic (SSB) has been the most cutting edge, he adopted some CRDTs I think for log relay, why not also for identity? Skip to 11:45 into the video, the algorithm/cryptography for it isn't that hard either: https://www.decentralizedweb.net/videos/talk-better-algorithms-for-a-decentralized-webthe-gun-stack/ https://www.decentralizedweb.net/videos/talk-better-algorith... you could do it in SSB without needing gun!

xj9 8y ago
the only way to share identity in a crypto-cap system is to share privkeys, which is a big no-no. much, much safer to have multiple privkeys that are linked with signatures. you probably shouldn't think of ssb id keys as having a 1:1 relationship with a person. they are more like device keys, the person ID is a higher level construct that is expressed by publishing links that assert that a set of keys belong to the same agent.
- ChristianBundy 8y ago
  This is similar to how it works with applications like Signal: each device has its own keypair and a person can have multiple devices. The only difference is that currently we don't have a universal way to do this, although it is in the pipeline.
  - marknadal 8y ago
    You can think of keys as being a device key. But now you just kick the can back. You still have to have an account that manages the device keys, and you certainly don't want that locked down to a device - unless that device is the user's brain. So either way, you're still gonna have to use a system to manage it that looks 110% like the MIT Open Source security/cryptography code anybody can rip from us.
    - notriddle 8y ago
      > But now you just kick the can back. You still have to have an account that manages the device keys, and you certainly don't want that locked down to a device They need to mutually confirm it. If keyA says sameAs keyB, and keyB says sameAs keyA, then they should be considered merged.
    - xj9 8y ago
      there is no account only capabilities accept this, find peace
      - marknadal 8y ago
        Please don't, we need more competition in the space. If you guys do this, you'll shoot your user adoption in the foot. Do you really think XYZ millions of users moving from FB in the next decade, when they come to SSB or NAB, are going to choose the one that is intentionally more complicated/confusing/harder-to-use? Get passwords working in cryptographically secure ways and the world will be at more peace.
        xj9 8y ago
        competition implies taking different approaches. i don't think that the cap approach is inherently more confusing. the point is, there is more than one way to make a good UX on top of differing cryptographic primitives. you have one method, and that's fine, i think that capability security is a better approach so that's the path i'm taking. i don't care about millions of people. mass adoption is fine, but i don't care about the people who already have internet, smartphones, and need convincing to drop their shitty spyware android device. i care about the billions of people who are coming online in the next 5-10 years. i'm developing[0] a stack that integrates hardware, software, and p2p/mesh protocols to compete directly with telcos and OEMs. when you include hardware security, the user experience of per-device keys is much nicer. you need a passcode that is used to protect your device-entangled key and that's it. new devices pair like bluetooth, securely handshake, and publish `sameAs` depending on the type of device. users don't need to worry about anything beyond the device passcode. projects like dark crystal[1] make it easy to generate and distribute an emergency key that can be used to restore access to your devices if you forget your code. [0]: https://heropunch.io/ https://heropunch.io/ [1]: https://darkcrystal.pw/ https://darkcrystal.pw/