mirror of
https://gitlab.com/spritely/ocappub.git
synced 2024-11-26 07:03:03 +00:00
Add the rest of ocaps meet activtypub objects/actors and start of proxying
This commit is contained in:
parent
f71ad175b8
commit
2db8321793
53
README.org
53
README.org
@ -1127,7 +1127,11 @@ In the latter message, Alyssa sent her message, which also provided
|
||||
a path to Ben's, amongst her friends, encouraging people she knows
|
||||
to establish a social connection with Ben.
|
||||
Alyssa and Ben were able to coordinate to spread this communication
|
||||
amongst people they trust, but it is not spread further.
|
||||
amongst people they trust, but it is not spread further than to
|
||||
anyone who is explicitly handed access.
|
||||
(It's possible that someone can share the information when Ben or Alyssa
|
||||
asked them not to;
|
||||
|
||||
|
||||
This is mildly interesting, but things get much more interesting when
|
||||
we realize that inboxes can also themselves be capabilities.
|
||||
@ -1157,15 +1161,54 @@ moment, but for the moment we can say that Alyssa posting to the
|
||||
group is as simple as referencing its =@id=:
|
||||
|
||||
#+BEGIN_SRC javascript
|
||||
|
||||
{"@type": "Create",
|
||||
// this is the @id of the above referenced Group object
|
||||
"to": ["bear:?u=https://groupchats.example/group&t=eQshu8RiJ-9ozh2GKRATXN5-J6dcBVf_AYSMrJ6UEzE"],
|
||||
"actor": "https://social.example/alyssa/",
|
||||
"object": {
|
||||
"@id": "https://social.example/obj/cdWg7wv1mjrNf0C3vcxCjzPy3Z9tturSBv9_Ew8qe7E",
|
||||
"@type": "Note",
|
||||
"attributedTo": "https://social.example/alyssa/",
|
||||
"content": "Anyone tried out libresprite? I hear it's a fork of the old FOSS branch of aesprite."}}
|
||||
#+END_SRC
|
||||
|
||||
Now the group can forward this message to its subscribers.
|
||||
|
||||
Here's the interesting aspects of this:
|
||||
|
||||
- Alyssa's access to write to the group can be unique to her. We'll
|
||||
see how this can happen in the next section. This means that it's
|
||||
also easy for the list administrator to unsubscribe her: they can
|
||||
just revoke the capability.
|
||||
- As said before, the capability Alyssa has here only allows her to
|
||||
post messages, not do moderation.
|
||||
- Each subscriber on the group has given the group a specific
|
||||
capability for their subscription. That means that the messages
|
||||
should go through to them "for free" unless the user explicitly
|
||||
chose to revoke the capability (but they probably would have
|
||||
manually unsubscribed instead).
|
||||
|
||||
** Adding attenuation, revocation, accountability, and composition
|
||||
|
||||
That's all good and well, but even reading the above might hint that
|
||||
we are missing some things. *How* is Alyssa's capability limited to
|
||||
posting but not administrating? *How* can both the susbscribers and
|
||||
the servers both know where messages are "coming from" / hold them
|
||||
accountable, and also have the power of revocation?
|
||||
|
||||
We are, in effect, now back to [[*Extending the car key metaphor][Extending the car key metaphor]] but
|
||||
without having explained how it works... but we know what we have
|
||||
claimed, that it is possible to have *delegation*, *attenuation*,
|
||||
*revocation*, *accountability*, and *composition*.
|
||||
Thus far we have only shown how delegation works: it is easy enough
|
||||
to copy around a capability url / bearcap.
|
||||
How about the rest?
|
||||
|
||||
*** The power of proxying
|
||||
|
||||
|
||||
** The power of proxying
|
||||
|
||||
|
||||
** True names, public profiles, private profiles
|
||||
*** True names, public profiles, private profiles
|
||||
|
||||
** Rights amplification and group-style permissions
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user