Conversation

Notices

1. Adam Marcus (marcua@hachyderm.io)'s status on Thursday, 04-Jan-2024 00:03:15 JST Adam Marcus

   This proposal to separate your ActivityPub identity from the server on which you reside is promising (and addresses my biggest gripe with AP), though I'm naive to the process. How far could it be from making it into the standard, and what sort of migration pains would implementations like Mastodon face?

   https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md

   • silverpill (silverpill@mitra.social)'s status on Thursday, 04-Jan-2024 00:03:07 JST silverpill

     in reply to

     @marcua I'm still working out the details, but here is what I think could cause migration pains:

     - With FEP-ef61, one account can use multiple servers. But many existing projects are designed for one-to-one relationship, and in these cases a lot of internal refactoring might be required.
     - It changes how moderation works, in particular instance blocks. I think instance blocks will remain effective, but will be less effective than today, and a lot of people may not like it.
     - It changes privacy expectations, because messages are signed and can be forwarded without asking a permission from an originating instance. Many protective measures like authorized fetch and follower-only visibility will likely be weakened. I think encryption standards must be developed to offset this.

   • Adam Marcus (marcua@hachyderm.io)'s status on Thursday, 04-Jan-2024 00:03:14 JST Adam Marcus

     in reply to

     • silverpill

     Ah! I didn't credit the author @silverpill! I apologize!

   • silverpill (silverpill@mitra.social)'s status on Thursday, 04-Jan-2024 02:56:13 JST silverpill

     in reply to

     @marcua AFAIK atproto doesn't have private messages yet: https://github.com/bluesky-social/atproto/discussions/121. Some Nostr apps may have encryption, I'm not sure which ones.

     I think our main source of inspiration should be Matrix, which is also federated and supports encryption for both direct messages and entire rooms.

   • Adam Marcus (marcua@hachyderm.io)'s status on Thursday, 04-Jan-2024 02:56:14 JST Adam Marcus

     in reply to

     • silverpill

     @silverpill This was so helpful, thank you! Ouch on the last one. Is that something the atproto team has addressed? Given this proposal and that protocol use DIDs, I wonder what else one could take inspiration from.

   • silverpill (silverpill@mitra.social)'s status on Thursday, 04-Jan-2024 03:06:45 JST silverpill

     in reply to

     @marcua Secure Scuttlebutt also uses encryption: https://ssbc.github.io/docs/ssb/end-to-end-encryption.html

   • silverpill (silverpill@mitra.social)'s status on Thursday, 04-Jan-2024 05:27:35 JST silverpill

     in reply to

     @marcua FEPs? They are just proposals, and may never become standards. I can only say that the first FEP-ef61 implementation may appear somewhere in the middle of 2024.

   • Adam Marcus (marcua@hachyderm.io)'s status on Thursday, 04-Jan-2024 05:27:36 JST Adam Marcus

     in reply to

     • silverpill

     @silverpill Makes sense! Thank you!

     Curiously, how much time do these RFCs typically take from being accepted/rejected from the standard?

   • silverpill (silverpill@mitra.social)'s status on Thursday, 04-Jan-2024 10:59:31 JST silverpill

     in reply to

     • bryan newbold

     @bnewbold @marcua did:apkey does not support key rotation. But other DID methods could be extended in the same way as did:key

     For example did:web -> did:apweb. The base DID method describes an identity, and "ap" extension describes how to access associated data via DID URLs

   • bryan newbold (bnewbold@social.coop)'s status on Thursday, 04-Jan-2024 10:59:32 JST bryan newbold

     in reply to

     • silverpill

     @silverpill @marcua how would key rotation work with did:apkey (based on did:key)? not allowing for key rotation feels a bit brittle for a longer-term identity.