#social 2019-02-24
2019-02-24 UTC
# 
fr33domlover In OCAP-LD, is it okay if in an invocation proof object, the "capability" member isn't a URI, but instead if the whole delegation object?
# fr33domlover So that when you invoke a capability, you provide the actual delegation you've been granted
xmpp-social joined the channel
# fr33domlover cwebber2, I have a new idea regarding who "hosts" capability delegations! Last time we talked about it we observed that either the delegator stores them, or the receiver of the delegation does. I suggested to do the latter, so that the responsibility is on the invoker, the user, and not on the server granting access. But I just realized, that in order to be able to revoke a capability, and for a user to
# fr33domlover see which capabilities they have granted, the server has a list of them anyway! Not necessarily the JSON objects, just the IDs, the invoker and caveats. So, if I send an invocation, in which the capability is specified as a URI, like in the OCAP-LD spec, the server can check it against its DB, and the signed delegation document never even needs to exist at all! That both saves network usage, and relieves
# fr33domlover the server from hosting burden. What do you think? Did I explain properly? ^_^
# fr33domlover It also saves 1 of the 2 required crypto signature verifications, because the server can trust what it puts into its own DB
# fr33domlover Even when using distributed storage, when you send an invocation of a revokable capability, very likely the issuer of the capability has all the info about it and it only needs to be published for the purpose of making delegation chains (or to make the application have minimal state; store just your private key and put everything else on distributed storage, allowing not to rely on any local database, but
# fr33domlover that's not the case on the fediverse, at least not yet)
ajordan and Guest84 joined the channel
# 
cwebber2 fr33domlover: you're right that in order for a server to revoke a capability, it needs to see it... though it could not hold onto it normally, and then upon seeing the capability abused, decide to revoke it, in which case it decides having seen it recently presented. But you're right that that's one way to do it.
# nightpool[m] i don't think it would make sense to define the icon nested inside of the actor, since it's supposed to represent some sort of independent resources?
# nightpool[m] But maybe defining an icon or icon attachment on the post would make sense?
# nightpool[m] hmm?
# nightpool[m] what's wrong with the thing I suggested?
# nightpool[m] sucks ig but i also see why it happens
# nightpool[m] My guess at what would happen is that mastodon would process your actor object and then change it for all of your posts including previous ones
# nightpool[m] since they have the same URI
# fr33domlover cwebber2, technically when using some content addressable storage, it's still storage and the content is being hosted, even if collaboratively in a distributed manner. I agree that it does mean no specific authority is the host, but even in that case, it doesn't change the picture much in practice: Technically, if you e.g. put the delegation on IPFS, every time a peer receives an invocation it can fetch
# fr33domlover the delegation from IPFS, verify its own signature on it, and decide to trust it. But in practice, this holds only if you really do literally fetch it from IPFS every time. If you use a local separate cache of all delegations you've granted, you can just look there instead (no need for network requests, no need to verify signatures), and we're back to the case where the delegation JSON isn't really used.
# fr33domlover But I agree the "nobody hosts it" concept is valuable regardless of these details
# fr33domlover In my use case there are (so far) no use of delegation chains, so simply remembering the delegations in the local DB is perfect. In the case delegation chains are created (which totally may become part of my use case soon), yeah it would be nice to just place stuff in content adressable storage. I'm waiting to see the next spritely demos ^_^