[HN Gopher] Keyhive - Local-first access control
___________________________________________________________________
Keyhive - Local-first access control
Author : dannyobrien
Score : 157 points
Date : 2025-10-02 00:12 UTC (22 hours ago)
(HTM) web link (www.inkandswitch.com)
(TXT) w3m dump (www.inkandswitch.com)
| chr15m wrote:
| Cool. I think you could use a CRDT (even a simple LWW structure)
| on top of Nostr which already works and has all of the properties
| you are looking for.
| jakelazaroff wrote:
| Could you explain how, for people not familiar with Nostr?
| chr15m wrote:
| On further review this is quite a lot further developed than
| what I suggested above. Sorry for the noise!
| pvh wrote:
| It does indeed turn out to be a difficult and subtle
| problem. We've tried to balance minimizing novelty (always
| risky in cryptographic systems) with achieving the various
| security and scaling properties we're looking for. We're
| very lucky at Ink & Switch to be working with Brooke
| Zelenka on this one.
| erlend_sh wrote:
| We're evaluating Keyhive for use in our distributed chat
| application and my colleague wrote an in-depth explainer on
| Keyhive's underlying Key Encapsulation Mechanism BeeKEM, which is
| a decentralized offshoot of TreeKEM used in MLS:
| http://meri.garden/a-deep-dive-explainer-on-beekem-protocol/
| ctm92 wrote:
| That callout card on the top of the site really messed with my
| brain with it being slightly tilted
| Xss3 wrote:
| Oh man i hate that with a passion.
|
| Devs, why?
| eqvinox wrote:
| Same here, plus the underlining is seriously triggering me o.O
| stronglikedan wrote:
| Probably designed by a "full stack developer" instead of a
| designer.
| NeutralForest wrote:
| Ink and Switch has been such a source of joy for me. I like
| reading their articles because they come from such a different
| place than what you currently see in most software (Cloud based
| subscriptions). Just a breath of fresh air backed by cool tech
| and cool people. Thanks!
| benchloftbrunch wrote:
| Note: this has absolutely nothing to do with the Windows
| registry, despite the name
| Too wrote:
| Their claim that every request goes through the hot path of a
| central auth db is stretching the truth quite a bit. With Oauth2
| you get a signed access token once from the Id Provider, then you
| reuse this token several times until it's given expiry time has
| run out. It is up to the resource server to validate the token
| scope, signature and the expiry time. This can be done offline as
| long as the resource server has the public key of the IdP. Ssh
| certificates work the same way.
|
| Obviously, now the resource server instead becomes your central
| guard of access, and is far from a local-first crypto based
| solution as they describe. Just that the way it's pictured
| sounded overly dramatic.
___________________________________________________________________
(page generated 2025-10-02 23:01 UTC)