#social 2019-01-24
2019-01-24 UTC
xmpp-social and cwebber2 joined the channel
# 
JasonRobinson[m] cwebber2 (IRC): will be there
# fr33domlover Hi people!
# fr33domlover OCAP-LD question: Who hosts the capability delegation document?
# fr33domlover cwebber2, ^
# fr33domlover ^_^
# fr33domlover Say object@server1 delegates capability to user@server2
# fr33domlover In the spec, the @id of the delegation is at server 1, but that seems to make little sense to me unless that id is meaningless, because server2 is the one using the capability, they need to make sure not to lose it etc. while server1 can do send-and-forget
# fr33domlover (server1 signs the delegation, they can always verify their own signature even if they receive it from someone else)
# fr33domlover cwebber2, suppose they're involved :) in my use case I mean. But yeah could be ipfs too yay
# fr33domlover cwebber2, I mean if entityA gives many capabilities to a variety of people, and it has to host them all, seems kind of heavy
# fr33domlover cwebber2, like it would be nice if people wanting access to a resource have to host the delegation they receive
# fr33domlover cwebber2, yeah it's usually the opposite like you host what you write
# fr33domlover but maybe in this case
# fr33domlover do it the opposite way?
# fr33domlover cwebber2, that's a nice idea :) I'm happy to consider and try stuff, I'm just starting to implement federation for my app so I'm open to new stuff. But I also want to get started with something, to code some initial actual method and start federating. I'm leaning towards people hosting delegations they receive and the server doesn't store them at all, only problem is that the delegation @id would be
# fr33domlover meaningless, I saw you opened an issue about making the @id not required
# fr33domlover And this would be wonderful here
# fr33domlover Because the target doesn't even store the delegation (there's no need to; it receives it later from remote users who want to invoke it)
# fr33domlover Hmmmmmmm on the other hand hosting it is easier to be by-the-spec and do stuff the way the fediverse does :p
# fr33domlover cwebber2, so if I'm a car sending people car keys, I "host" all the delegations for them?
# fr33domlover cwebber2, you mean you only keep the ID of the delegation and not the whole JSON-LD document?
# fr33domlover cwebber2, hosting posts and profiles is a bit different because public material ends up being cached in a million places; I guess ocap docs are generally personal, private, you just host them in 1-2 places at most (well, unless there's long delegation chains, but I guess without hierarchical organizations etc. there won't be many chains longer than 2-3)
# fr33domlover We sign the capability in order to hand it out to others right? In which case, we don't need to host it, it just wastes space. And if we keep it loca, there's no need to sign it, because we're the only ones verifying it and we trust ourselves (am I right? maybe corner cases exist?)
# fr33domlover I do see one clear case we "remember" capabilities we send: When we want to be able to revoke them, we keep some ID so that we can revoke by deleting the ID from our DB
# fr33domlover If I give someone access to edit my stuff, I definitely want to be able to revoke this access
# fr33domlover Oh I see! Yeah you'd be handing out the entire chain
# fr33domlover In my case there's no chain, I mean, just handing out top-level delegations
# fr33domlover Maybe that was confusing me
# fr33domlover I see now :)
tantek joined the channel