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?
|
** 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
|
* How to build it
|
||||||
** Object capabilities (ocaps)
|
** Object capabilities (ocaps)
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user