#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.
#
cwebber2
however, the alternative of using "nobody specifically hosts it" as with the magenc examples I'm doing in Golem is better I think, in the case that you want to certificate-style ocaps
#
cwebber2
then nobody needs to "decide" who holds it
#
aaronpk
can a post include a specific icon for the actor, or will the actor object always be looked up at the actor URL? I'm trying to override the icon on a per-post basis
#
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?
#
aaronpk
I have a new feature on my site that I was trying to translate to activitypub but it looks like I can't
#
nightpool[m]
hmm?
#
nightpool[m]
what's wrong with the thing I suggested?
#
aaronpk
I mean if anything supported that sure
#
aaronpk
just kinda irritating that I can't demo this with mastodon but it works fine for everyone following my microformats feeds
#
nightpool[m]
/shrug
#
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
#
aaronpk
hm yeah
#
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 ^_^