This is very generic and broad so no worries if anyone doesn’t really have an answer but I was wondering if there were any structural decisions anyone might recommend to someone building an ActivityPub implementation that would be good or better help with incorporating OCAP, down the line?
While I know it’s been said that extending the AP spec. with OCAP should be relatively trivial and undisruptive to the currently existing spec., reasoning about it is hard to do when there isn’t any concrete examples to work off of or set design in mind (yet).
With an implementation in a still unfinished state, revising things now might be easier if there are any particular structural or design concepts to keep in mind. I think I remember seeing somewhere that certain elements of Pleroma may’ve been designed with this future capability in mind (though I can’t verify that) so I figured I’d ask, in case anyone had any experience and/or recommendations they might find pertinent.
We use OCAP for private media (attachments) and this works well although it would not have been (and actually wasn’t) my first choice for privacy in decentralised situations. My personal opinion is that security through obscurity when you’re potentially spreading long-lived “keys” all over the planet is a poor choice. Sure, you can invalidate the keys but there’s no protocol for updating these to the viewer and you’ll only know to invalidate them after a breach has occurred, so the horse has already left the barn so to speak. But as long as you are aware that fuskers have been around for at least a couple of decades and your private photos are eventually going to end up in the public domain, sure - go ahead.
It’s a pretty big fail for use as an ‘id’ for activities; at least in a conversational platform. You might get away with it on a microblog but then your stuff wouldn’t federate with any of the numerous conversational platforms. It may not be obvious at first glance but it’s difficult to thread a conversation when every viewer is composing and reacting to the same posts but using completely different message-ids from everybody else. The only way I can see this ever working is if you provide another field in the activity to store the access token - or turn id elements an array, where the first element is the canonical form of the id and the second is an access specific url. Otherwise it just creates a mess.
Ironically bearcaps might help here. They don’t do anything to add security (which was the initial claim). But they do provide a syntax for representing the url and token as separate components and would allow you to separate the two internally so you can deal with canonical URLs without the access component in order to compare message-ids; and only add the access component when fetching. So in this sense it would work like the array I mentioned above. I haven’t yet tried this because bearcap support is still a bit sketchy across the fediverse and implementing it in this manner would involve a pretty major rewrite on my platforms - but it might just work.