Since I occasionally find people focused on the same kind of problem that
I’m trying to tackle with this project, and I have a terrible tendency to
share my thoughts informally, I figured it would be a good idea to post a
kind of roadmap for the project.
This isn’t going to be fixed in stone forever. But its general outline should
remain more or less intact.
The overall goal is to “fix” the problems of the World Wide Web by addressing
the privacy and security needs of the users and by embracing that most users
will use a multitude of devices, some of which are shared. Finally, it’s
important to understand that real-time usages and eventually consistent usages
of the web are both required, and that there are good uses for both the “document”
and the “application” web, as some people call it.
I’ve written elsewhere on the problems of the web, and a high level overview
on how to move forward:
The purpose of this post is to outline a rough roadmap of “chunks” that need to
Provide some kind of legacy free, reasonably simple socket abstraction. This
is what packeteer is about. And
while that project still can use some love, it’s “done enough” to move forward.
Provide peer-to-peer connectivity that allows for multiple networking links
and multiplexes individual “channels”, each of which can have its own
reliability capabilities and carries its own encryption context. This is what
channeler is about, and I’d call
it around 30% complete as of today.
Provide a kind of identity and authorization framework. This is going to be
somewhat abstract, not necessarily something directly expressed in a
networking protocol. The idea is to allow for some limited delegation of responsibilities.
Provide a filesystem-like interface for synchronizing documents (and
applications) in a scalable, eventually synchronous fashion. This should
fulfil the document web use cases, but by building on the previous two
milestones should be secure and private by default.
Use the filesystem-like interface for providing also real-time communication
capabilities. This isn’t as difficult as it sounds, but worth separating
into its own milestone.
Extend the filesystem-like interface to better work with content types.
Content types should be the driving force behind how a real-time API here
works, and how documents are to be manipulated. The aim is to not leave
everything to server implementors as in REST, but follow an approach that
looks closer to how e.g. schema.org represents data.
Provide a real-time API schema based on e.g. CapTP
to demonstrate that the application web needs can be served more sanely
than via REST’s data silos - for if and when the document web approach
simply will not work.
Build sample applications. This can really be happening at any stage, and I
have a few ideas for earlier stages. But the whole thing has to lead somewhere,
so it’s worth putting a final milestone here.
This overview has always been in my head, and it’s somewhat reflected in the
grant roadmaps I’ve submitted. But I don’t think I’ve ever communicated it
publicly, and that’s been a mistake.