Hi @hrefna I just a FYI on https://versia.pub a federation protocol "heavily inspired by ActivityPub" which I just bumped into via @erlend .. didn't have a deep look yet, but thought it might be interesting given your own musings re:FeatherPub.
-
somehybridreplied to Jesse π«π· :versia: last edited by
@jessew @hrefna @jenniferplusplus @smallcircles @erlend @anders the only issue i see (from a quick look) is storing the keys, bc you never know if a malicious server owner may modify the public key and read traffic
~~nerds being overly pessimistic~~
-
Jesse π«π· :versia:replied to somehybrid last edited by
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] @[email protected] one thing that was very important to me and the team while designing Versia was prioritizing simplicity and correctness over complex sets of features (such as end-to-end encryption or large cryptographic schemes with revocable keys, certificates, devices and such)
We've settled on a threat model where you trust your instance administrator to not tamper with your keys, because otherwise it could overcomplicate the protocol and make it harder for small developers to create independent implementations
The thing that we try to remember during spec design and integrating feedback is βhow complicated would this entire thing be to implement from scratch for anyone that doesn't have a whole team of professional engineers?β. If you or anyone else can figure out a way to restrict the threat model in a simple way, that would be awesome, because we haven't been able to for now.
this is also why pure nomadic identity isn't really a thing here btw, and instead the βdelegationβ system exists, because it's really simple to implement in code -
Jenniferplusplusreplied to Jesse π«π· :versia: last edited by
@jessew @hrefna @smallcircles @erlend @anders
The recipient of a message can replay the whole message verbatim to a 3rd party, and it will validate. If the path component included the host name, that would go a long way toward mitigating that concern. But honestly, I would really recommend just specifying rfc 9421 signatures. It's gone through years of review, and there's at least a chance that devs can find library support for it, rather than having to roll their own. -
Jesse π«π· :versia:replied to Jenniferplusplus last edited by
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] Interesting point, then if I've understood correctly I would consider this as intended behavior: the point of the signature is to prove the authenticity of a message, not to provide confidentiality (adding things like end-to-end encryption would probably be out of scope for us for reasons explained at https://mk.cpluspatch.com/notes/9xynutbevkyr01mf).
If the messaged is replayed verbatim to a third party, then it should probably validate (this would also allow for easier βrelay serversβ such as what ActivityPub has).
I will also specify the purpose of the signature in the docs right now -
Jenniferplusplusreplied to Jesse π«π· :versia: last edited by
@jessew @hrefna @smallcircles @erlend @anders
You can design your protocol how you like, but intentionally excluding confidentiality as a concern would be a deal breaker for me and I just wouldn't ever implement it. -
Hrefna (DHC)replied to Jesse π«π· :versia: last edited by
Just to chime in: implementing forwardable tokens is a whole thing and quite complex to do well (c.f., JWT).
Usually signatures are used as a way to verify the _origin_ of the message rather than the _authorship_ of the message. It sounds like your priority is on verifying the authorship (and non-tampering, naturally) rather than the origin?
-
@hrefna @jessew @jenniferplusplus @smallcircles @erlend @anders ActivityPub has (sort of) forwardable signatures via LD Signature signing and software has increasingly dropped support for generating them because they're almost always a mistake.
They mean blocks don't work. They mean that messages you sent a year ago can be replayed too, with interesting implications
Outside of a few minor applications I think they're a bad idea -
@hrefna @anders @erlend @jenniferplusplus @jessew @smallcircles also lots of assertions are made here about the efficiency of WebSockets Vs HTTP requests, but do they actually match reality? In particular, are you comparing against HTTP2 with reasonable tuning? (Or even HTTP3, but that introduces a lot of variables)
-
@anders @erlend @hrefna @jenniferplusplus @jessew @smallcircles even if WS are more efficient, they are going to require bespoke load balancing infrastructure on your ingress proxies. I doubt it's actually worth it
-
April The Pink ββΎβΆββ€β½βreplied to Jenniferplusplus last edited by@jenniferplusplus @jessew @hrefna @smallcircles @erlend @anders we are still planning on e2ee, but as a extension. This isnt about confidentially here, the current protocol spec should allow for repeats from other instances, but that should be able to be limited using extensions. We currently dont have the capacity for that as a three person team with many other things on our ToDo, but we are always happy to accept PRs