Add ocaps as capability urls

This commit is contained in:
Christopher Lemmer Webber 2019-07-23 17:42:26 -04:00
parent 8424151300
commit 812c7dde2d
No known key found for this signature in database
GPG Key ID: 4BC025925FF8F4D3
1 changed files with 48 additions and 1 deletions

View File

@ -947,16 +947,61 @@ 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
Now that we have the good mental structure to think about how to build
this system, we need to assemble the pieces.
Since ocaps are the foundation, we need to think about how to represent
ocaps.
Note that there are many more ways to represent ocaps than the
mechanisms we are presenting; these have been chosen for their
simplicity and ease of implementation.
*** Ocaps as capability URLs
That's all good and well, but real-world metaphors
The easiest and simplest way to implement ocaps would be to use
simple but statistically unguessable "Capability URLs".
For example:
https://site.example/obj/sXJ9WWj6LRLCggZrjzfaeDutb8352OqSR0m2yg8XBkA
To have the address both brings you to the corresponding object
and gives you access to it.
(Or, in ocap terms, a capability URL "does not separate designation
and authority".
Most, and certainly the easiest to implement, ocap systems follow
this pattern.)
For such capability URLs to work, both sharing and accessing them
must be done through secure channels.
You may have seen these yourself before.
For example, on Google Docs there is the option to share the document
(and select whether you'd like to give full read/write access or just
read access) by sharing a URL.
Now you can just copy that URL to a friend and they have access.
Capability URLs are very easy to make and work with.
Unfortunately, there are a lot of [[https://www.w3.org/TR/capability-urls/][careful considerations]] one must
make when using capability URLs.
Most of these come from a conflict of expectations when working with
contemporary web browsers and web servers: by default, browsers leak
"where you came from" to "where you went to" via the =Referer= http
header (very dangerous when knowing where you came from gives you
additional power!) and servers log URLs to commonly insecure access
logs.
*** Ocaps as bearcaps
**** What this doesn't prevent (conflicts with browser assumptions)
*** Ocaps meet ActivityPub objects/actors
** The power of proxying
** True names, public profiles, private profiles
@ -967,6 +1012,8 @@ That's all good and well, but real-world metaphors
* Limitations
**
* Future work
** Petnames