mirror of
https://gitlab.com/spritely/ocappub.git
synced 2024-11-22 21:23:02 +00:00
Add the "Ocaps meet human relationships" section
This commit is contained in:
parent
d824ed40d1
commit
5530ffff57
54
README.org
54
README.org
@ -892,7 +892,59 @@ in fact, very similar to how we program every day.
|
||||
than they are ocaps), so the name "object capability" was chosen to
|
||||
distinguish between the two.
|
||||
|
||||
** Ocaps meet human relationships
|
||||
** Ocaps meet social relationships (or: just in time authority)
|
||||
|
||||
Some systems that try to confine authority today are called "sandboxes".
|
||||
If you have had experience with present-day sandboxes, you might be
|
||||
skeptical, based on those experiences, that an ocap type system will work.
|
||||
That would be understandable; in many such systems a user has to
|
||||
pre-configure all the authority that a sandboxed process will need before
|
||||
the process even starts up.
|
||||
Almost inevitably, this authority doesn't end up being enough.
|
||||
Time and time again, the user opens the sandboxed process only to find that
|
||||
they have to "poke another hole" in the system.
|
||||
Eventually they let too much authority through; out of frustration, the
|
||||
user might simply pass through nearly everything.
|
||||
|
||||
Thankfully, ocaps don't have this problem.
|
||||
Unlike many traditional sandbox systems, we can pass around references
|
||||
whenever we need them... authority can be handed over "just in time".
|
||||
|
||||
This is less surprising if we consider the way passing around ocap
|
||||
references resembles the way people develop social relationships.
|
||||
If Alice knows Bob and Alice knows Carol, Alice might decide it is
|
||||
useful to introduce Bob to Carol.
|
||||
We see this all the time with the way people exchange phone numbers
|
||||
today.
|
||||
"Oh, you really ought to meet Carol! Hold on, let me give you her
|
||||
number!"
|
||||
|
||||
#+BEGIN_CENTER
|
||||
[[file:./static/granovetter.png]]
|
||||
|
||||
/One of the Granovetter Diagrams shown in [[http://erights.org/elib/capability/ode/index.html][Ode to the Granovetter Diagram]]./
|
||||
/Pardon the geocities-era aesthetic./
|
||||
#+END_CENTER
|
||||
|
||||
In fact, thinking about such social relationships have long been at
|
||||
the heart of ocap systems.
|
||||
One of the most famous (and informative) ocap papers is one called
|
||||
[[http://erights.org/elib/capability/ode/index.html][Ode to the Granovetter Diagram]] (a truly remarkable paper which shows
|
||||
how many complicated systems, including basic money and financial
|
||||
transaction infrastructure, can be modeled on ocaps).
|
||||
In this paper "Granovetter Diagrams" such as the above are introduced,
|
||||
showing how ocaps flow through a system by social introductions.
|
||||
In fact the above diagram is pretty much exactly the same as our phone
|
||||
number exchange... "Alice is sending Bob the message =foo=, which
|
||||
contains a reference to Carol, and now Bob has been introduced to /
|
||||
has access to Carol."
|
||||
|
||||
It turns out that Granovetter Diagrams have their origin in sociology,
|
||||
from a famous paper by Mark S. Granovetter named
|
||||
[[https://www.sciencedirect.com/science/article/pii/B9780124424500500250][The Strength of Weak Ties]].
|
||||
It's good news that much of thinking about ocaps has been based on
|
||||
how human relationships develop in sociology, since we are now about
|
||||
to use them to build a robust social network.
|
||||
|
||||
* How to build it
|
||||
** Ocaps we can use in our protocols
|
||||
|
Loading…
Reference in New Issue
Block a user