mirror of
https://gitlab.com/spritely/ocappub.git
synced 2024-11-26 23:23:03 +00:00
Must we boil the ocean?
This commit is contained in:
parent
be27c3e64f
commit
43a856e86c
17
README.org
17
README.org
@ -683,6 +683,23 @@ But the framework for all of this is object capabilities.
|
||||
|
||||
** Must we boil the ocean?
|
||||
|
||||
All this sounds fine and well, but we are pressed with a problem: we
|
||||
/already have/ ActivityPub implementations in the wild, and those
|
||||
implementations filled in the holes in the spec in the best ways they
|
||||
knew how.
|
||||
|
||||
We do not want to have to throw away the network we have.
|
||||
As such, this document does not try to solve all possible problems.
|
||||
For example, a Webfinger-centric interface is roughly incompatible
|
||||
with Tor onion services, even if supporing such services would be
|
||||
desirable and could be more easily accomplished with a [[https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/making-dids-invisible-with-petnames.md][petname system]].
|
||||
As such, this document simply assumes that we will live with
|
||||
webfinger-based addresses for now, even if not optimal for the long
|
||||
term.
|
||||
|
||||
Incremental improvement is better than no improvement at all, and
|
||||
there is a lot we can make better.
|
||||
|
||||
* How to build it
|
||||
** Object capabilities (ocaps)
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user