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.
-
Jesse π«π· :versia:replied to smallcircles (Humanity Now π) last edited by
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] Hi, thanks for the compliments!
Couple points raised here that I'm going to try to answer1. the signature based authentication algorithm is susceptible to being replayed.
I care very much about security, would you mind sharing some details so that we could work on fixing any issues?2. there's no real way to negotiate protocols.
There is the Nodeinfo for discovering which protocols an instance supports (such as https://mastodon.social/nodeinfo/2.0) but you're right that it's not actually mandated inside the protocol, mainly because we've been looking for any better ways to do protocol negotation. If you're interested, the reference implementation tries to search for/.well-known/versia
in order to find out if Versia is supported (otherwise it falls back to ActivityPub), but this is not ideal.3. websockets as a lower overhead transport ???? What
According to our testing, this actually makes a lot of sense for very high-volume traffic, as keeping a WebSockets connection alive takes basically zero resources.
The goal with that particular idea is to allow for a king of "request batching", so instead of sending each entity in its own individual HTTP request, with the associated overhead, hundreds of entities could be sent at once rather easily, significantly reducing the load on instances (it's pretty crazy how efficient WS is)
If y'all have more questions or suggestions, I'd be happy to listen (even if it'd introduce breaking changes) -
Risottoreplied to Jesse π«π· :versia: last edited by
@jessew @hrefna @jenniferplusplus @smallcircles @erlend @anders
Was gonna say "is susceptible to replays" was slightly vague
Off the top of my head, is there a nonce-challenge (or otherwise time-stamped) way to make it so an activity is valid once?
I could totally be wrong
I love that you made something new, it's awesome π₯°
-
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