mirror of
https://gitlab.com/spritely/ocappub.git
synced 2024-11-26 07:03:03 +00:00
Add ocaps as capability urls
This commit is contained in:
parent
8424151300
commit
812c7dde2d
49
README.org
49
README.org
@ -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
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user