[annotator-dev] Usernames and groups

Wed Dec 11 19:23:59 UTC 2013

On Wed, Dec 11, 2013 at 2:01 AM, Mitar <mmitar at gmail.com> wrote:

> Hi!
>
> On Tue, Dec 10, 2013 at 3:11 PM, Randall Leeds <tilgovi at hypothes.is>
> wrote:
> > Of course, the other approach is to lift all of this out of the
> annotation
> > itself and manipulate n ACL as a separate object with its own API. The
> data
> > of the annotation, then, never crosses a server boundary in a federated
> > environment. It is purely local.
>
> You mean, ACL data for the annotation then never crosses the boundary
> in a federated environment. Probably we want annotation data to be
> federated. ;-)
>

Right! :)

>
> Maybe projects like Diaspora, XMMP and pump.io addressed this in some
> way already?
>

I think Diaspora federates by posting activity directly to the pod(s) of
the receiving user(s) of non-public activity, each post encrypted with the
public key of the recipient. It uses WebFinger to discover the key and the
URL to post to.

Pump.io doesn't deal with this at all, AFAIK. It's not core to
ActivityStreams.

XMPP itself probably doesn't deal with this, either. There are extensions
like server-side block lists, others for sharing folders, but XMPP is about
messaging. The recipient is on the envelope. Messages aren't objects of
collaboration. They don't have permissions.

There's also WebDAV, which has an ACL spec:
https://www.ietf.org/rfc/rfc3744.txt. There, the envelopes are properties
associated with a URL, fetched and manipulated with new verbs like PROPFIND.

Yes, I like the idea of general standard of permissions on web
> resources. Web is already a distributed system. We might attach
> permissions on top of that as well.
>

HTTP 403 Forbidden. HTTP 200 OK. Authorization header.
How the header is interpreted is domain specific. HTTP Basic Auth, OAuth,
and various cookie schemes to pass credentials are all done in practice. We
have an abundance of standards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20131211/5838b9b4/attachment-0004.html>