Conversation

Notices

1. Angry Sun (sun@shitposter.world)'s status on Sunday, 24-Nov-2024 01:16:14 JST Angry Sun

   • silverpill
   @silverpill I'm reading: https://codeberg.org/fediverse/fep/src/branch/main/fep/fe34/fep-fe34.md
   
   soliciting your opinion on this: if I am using an object storage service and actor relative urls ( https://codeberg.org/fediverse/fep/src/branch/main/fep/e3e9/fep-e3e9.md ) should the objects absolutely be signed portable objects or would it be ok to just check the storage service url against the service listed in the actor object? I am being resistant to signing my objects but maybe I should just give in.
   • silverpill (silverpill@mitra.social)'s status on Sunday, 24-Nov-2024 01:16:14 JST silverpill

     in reply to

     @sun FEP-e3e9 is not my proposal. It doesn't seem to be compatible with FEP-fe34 security model (that means security is not proven), ties identity to actor document (you will likely need 1-to-many relationship to implement anything more complex than a micro blog), and doesn't support decentralized identities.

   • silverpill (silverpill@mitra.social)'s status on Sunday, 24-Nov-2024 01:24:22 JST silverpill

     in reply to

     @sun Putting keys into a DID is a correct approach. One identity should be able to manage multiple actors, for example there might be one personal actor and a number of group actors, or different personal actors for different social circles.

     I want to interoperate but only on FEP-ef61 terms. Other solutions might exist but FEP-ef61 is the only one that supports decentralized identities, and therefore suitable for P2P.

   • Angry Sun (sun@shitposter.world)'s status on Sunday, 24-Nov-2024 01:24:23 JST Angry Sun

     in reply to

     • silverpill
     @silverpill I am doing other things my own way like I am using did for ap id and the storage is linked to the identity via the did document rather than new fields on the actor object. i put all the key shit in the did and rely on that instead of putting it in the actor object since I'm using my did identity for more than ap
   • Angry Sun (sun@shitposter.world)'s status on Sunday, 24-Nov-2024 01:24:23 JST Angry Sun

     in reply to

     • silverpill
     @silverpill I am worried that I am doing things in a way that creates more work for ap implementors (if anyone wanted to interop with me which is questionable) but I am trying to put things attached to my did directly so I don't have to redefine them all over the place.
   • Angry Sun (sun@shitposter.world)'s status on Sunday, 24-Nov-2024 01:24:24 JST Angry Sun

     in reply to

     • silverpill
     @silverpill btw I am writing am object storage service implementation and it is almost done.
   • Angry Sun (sun@shitposter.world)'s status on Sunday, 24-Nov-2024 01:43:16 JST Angry Sun

     in reply to

     • silverpill
     @silverpill I am literally almost paralyzed by two incompatible ways forward, I should make a pragmatic decision and just support fep-ef61 but I'm obsessed by forcing as much through regular did resolution stuff as possible.
   • silverpill (silverpill@mitra.social)'s status on Sunday, 24-Nov-2024 01:43:16 JST silverpill

     in reply to

     @sun I think the future is peer to peer. In order to make ActivityPub work in a peer to peer environment, we need identities that do not depend on DNS in any way, such as did:key.
     For example, how do we use Iroh for transport (instead of HTTP)? It seems that FEP-ef61 and did:key is the only answer

   • silverpill (silverpill@mitra.social)'s status on Sunday, 24-Nov-2024 02:03:04 JST silverpill

     in reply to

     @sun And I'm not saying this because I think DNS is inherently evil. No, web-based identities and custodial keys is what most people should be using.

     But it is just happens that a lot of smart people care about crypto and p2p, and no one gets excited about linked data and oauth. In a technological sense, Fediverse is an inredibly boring place, and I want to fix that.

   • Angry Sun (sun@shitposter.world)'s status on Sunday, 24-Nov-2024 02:22:38 JST Angry Sun

     in reply to

     • silverpill
     @silverpill My main objection to did:key is just that I think there should be a master key you store away somewhere and then some way to assign a subkey that can be revoked or rotated that you use for signing your posts. fedi is kind of a low-risk identity but when you move to a DID and start using it everywhere I think the security becomes a lot more important. But right now the stuff I am building I support interacting with did:key just find, I just prefer did:web for identity I support for the owner's identity. maybe I'll add the ltitle bit to support both though.
   • silverpill (silverpill@mitra.social)'s status on Sunday, 24-Nov-2024 02:22:38 JST silverpill

     in reply to

     @sun Yes, applications should give users a choice.

     did:key is intended only for a small subset of power users and a corresponding secret key shouldn't be stored on a server. I would use it on a desktop FEP-ae97 client, perhaps connected to a hardware wallet.