#mastondon Friends!
Technical Discussion
165
Posts
69
Posters
689
Views
-
@scottjenson Private mentions aren't really private if they're not end-to-end encrypted. On a federated platform, you put a lot of trust on the servers, and it's not just the one you're on but also the one receiving the messages. What if I want to message a friend on Threads for instance? I don't know about you, but I don't trust Meta to just deliver the messages without using them to build a profile on me or improve their AI models, which are things I can't really opt out of since it's not my platform. The only way to avoid these things (to some extent) is to make it impossible for them to read my messages.
The good thing is you don't have to reinvent the wheel here, there are already a few attempts at standardizing encryted messages for ActivityPub: Evan put together the MLS over AP, Hollos also did something similar. Make sure to talk to them so we don't end up with yet another standard.@Varpie I did just check out Hollo (Hollos?) and it appears to be a server for just 1 account so it's not clear HOW it's handling this. (I'm not going to install it for just kicking the tires)
For me, the biggest issue is setting up/managing the keys. I'm hoping to find any implementation that shows how to do this?
It's not enough to show a technology demo, we have to have something mere mortals can turn on without a multiple step configuration process.
-
@Varpie I did just check out Hollo (Hollos?) and it appears to be a server for just 1 account so it's not clear HOW it's handling this. (I'm not going to install it for just kicking the tires)
For me, the biggest issue is setting up/managing the keys. I'm hoping to find any implementation that shows how to do this?
It's not enough to show a technology demo, we have to have something mere mortals can turn on without a multiple step configuration process.
@scottjenson True, handling the messages in a standardized way is one thing, but managing keys across multiple clients is the hard part here. The way I see it, there are 2 options:
- each client creates its own key, encrypted messages now need to be encrypted with multiple keys and the new clients don't have chat history (this could be mitigated by having existing clients with the decrypted messages send them to the server with the new key)
- there is some sort of handshake when registering a new client, that passes the private key from a registered client to the new one
The first option allows to handle each client separately, so we don't need the other device to be available and if we want to stop using a specific app, we can deregister it, but it requires senders to encrypt their messages n times, and as mentioned it makes it difficult to handle chat history.
The second option makes chat history trivial, but it puts a lot of trust on new clients, if we want to stop using it the rotation of keys is more complex. Also, each client needs to be able to handle the same type of keys, which isn't a given when using different apps.
I think for user experience, having each client generate its own key and asking older clients to re-encrypt messages with the new key can be better: there is no requirement to have the other clients active at the same time, but we can have the same handshake that would be required for passing PKs, to recover chat history. It also allows to give more granular control over which clients are active, kind of like seeing the active sessions for an account and being able to log off on other devices. -
@scottjenson True, handling the messages in a standardized way is one thing, but managing keys across multiple clients is the hard part here. The way I see it, there are 2 options:
- each client creates its own key, encrypted messages now need to be encrypted with multiple keys and the new clients don't have chat history (this could be mitigated by having existing clients with the decrypted messages send them to the server with the new key)
- there is some sort of handshake when registering a new client, that passes the private key from a registered client to the new one
The first option allows to handle each client separately, so we don't need the other device to be available and if we want to stop using a specific app, we can deregister it, but it requires senders to encrypt their messages n times, and as mentioned it makes it difficult to handle chat history.
The second option makes chat history trivial, but it puts a lot of trust on new clients, if we want to stop using it the rotation of keys is more complex. Also, each client needs to be able to handle the same type of keys, which isn't a given when using different apps.
I think for user experience, having each client generate its own key and asking older clients to re-encrypt messages with the new key can be better: there is no requirement to have the other clients active at the same time, but we can have the same handshake that would be required for passing PKs, to recover chat history. It also allows to give more granular control over which clients are active, kind of like seeing the active sessions for an account and being able to log off on other devices.@Varpie I just found https://holos.social/e2ee which explains how keys are generated per message and using the actor in activit Pub allows the sender to know if the recipient is capable of receiving an encrypted message. It seems pretty slick and looks like it's almost ux-free with a few unanswered questions.
-
@Varpie I just found https://holos.social/e2ee which explains how keys are generated per message and using the actor in activit Pub allows the sender to know if the recipient is capable of receiving an encrypted message. It seems pretty slick and looks like it's almost ux-free with a few unanswered questions.
@scottjenson This is great but it assumes a single device (private key) per account. What if I want to have a phone and a desktop? Whatsapp and Signal both "solve" this by having one main device (the phone) and connected devices that make use of this main device's private key, but in the context of having different applications connected to a fedi account, I'm not sure it would work too well.
-
@scottjenson This is great but it assumes a single device (private key) per account. What if I want to have a phone and a desktop? Whatsapp and Signal both "solve" this by having one main device (the phone) and connected devices that make use of this main device's private key, but in the context of having different applications connected to a fedi account, I'm not sure it would work too well.
@Varpie exactly. This is why I'm treating this topic as something potentially quite difficult. One of the incredible values of the fediverse is that I use multiple clients to manage my account and I'm worried that encryption will make that nearly impossible.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@julian I really tried. Maybe should have reached for AI. I'll look into that web+ap:// scheme, thank you!
-
@travisfw@fosstodon.org I don't blame you for not reading through the whole thread.
Suffice to say I think there is merit in using web+ap:// scheme at the browser (and possibly app) level.
PWAs can register themselves as a handler of those types (web+), and on the web side there are tricks to allow for the opening of them in the PWA or falling back to browser https.
It's worth experimentation, I think.
-
@julian it's complicated, isn't it. I was focusing on the narrower case of one app calling a default (or system dialog to choose) app to handle the post, rather than even necessarily involving the browser. But could one solution (somewhere in that veritably long-ass thread) serve the whole matrix of calling web->web, web->app, app->app, and app->web?
-
@travisfw@fosstodon.org short answer: no
Slightly longer answer: not yet
Long-ass thread (just from last month!): https://activitypub.space/topic/e00a0fd8-31d2-494e-bd8a-31eedcd16ac2/it-s-really-surprising-to-me-that-the-fediverse-hasn-t-agreed-on-a-standardized-way-to-open-cross-instance-activitypub-objects-and-instead-relies-on-links-that-open-in-the-browser
😅
-
#FediDev is there a generic Android intent for sharing to the Fediverse?
-
the type information is largely unnecessary and shouldn't factor into handling CRUD
Servers needs to know the core type / class in order to determine the "owner" of an object (actor, attributedTo, etc).
how does the server know which ids to assign and which ones not to?
The result property could be declared as special in the FEP. Servers will be required to assign IDs to embedded activities. What is a blank node identifier, id: null? Using this to indicate a need for ID is a good idea too.
I don't think side effect activities should be fragments.
lastly as:result itself maybe doesn't have these semantics defined, so should a subproperty or different property be used, or do we skip non-CRUD results?
Why skip non-CRUD results? I think side effects shouldn't be limited to basic activities like Create/Update/Add/Remove.
-
@silverpill @steve so we might need to recommend that these "side effect" activities in as:result SHOULD have fragment identifiers, to be able to refer to them later? or do we intend to never refer to them later? we could say they're transient activities so don't need to be referred to later (only processed in-order).
lastly as:result itself maybe doesn't have these semantics defined, so should a subproperty or different property be used, or do we skip non-CRUD results?
-
@silverpill @steve also the server's main responsibility being publishing and therefore needing to mint an identifier for the top level activity, we should ask if the server is expected to assign any inner ids as well? assigning ids changes the graph so it's not clear cut. <how does the server know *which* ids to assign and which ones not to?> is an open question (and maybe blank node identifiers are actually in practice required to avoid ambiguity?)
