Throughout our identity document series, we have assumed that we were
designing for domain hosting. This does not mean that we discard a
highly useful movement towards peer-to-peer (or P2P) networking.
Allow us to illuminate how we can see these approaches merge.
P2P networks enhance the freedom of online users to communicate with a minimum of dependencies on centrally managed infrastructure. Even though the popular press got hold of applications such as music downloads, this is by far not the only use of these systems. In their purest form, they embody the most liberating principles of a well-oiled Internet.
Distribution of Control
The main reason to design a protocol as a P2P protocol is to distribute control over the network. This ultimately sets end users free, and allows them to communicate with less constraints. And yes, this allows so much that it even supports illegal activities, but that can be said of all mechanisms, even seemingly harmless ones.
In general, the added value of P2P networks, their promise of independency, greatly outweighs these exceptional corners that are indeed not as easy to catch in one large net.
The Internet was originally meant to distribute control. In our architecture, we implement this true to heart by making it easier for users to have their own online presence through a powerful, modern hosting stack. P2P networks take the opposite approach, where there is not even the infrastructure of current protocols, DNS and routing systems but even that is internalised into the network. It's a more accellerated form of the same idea.
The reason why control should be distributed is that we can see the opposite motion in today's Internet, along with its devastating effects. Most of us have accounts at Facebook because most of our friends do — and those who have decided not to sacrifice their privacy for the convenience of messaging that can be achieved just as easily with XMPP or even IRC are under a constant mild pressure from their peers, and are regularly overlooked.
But what does it mean to have an account at Facebook? It means agreeing with a privacy regulation that is not in line what we as individuals want. It is agreeing to be scanned, grouped and pattern matched, and more so, to be subjected to advertising triggers that we know will work. In the worst use ever, it's a means to get a president elected into a large country through customised sweet talk. This is not a World that serves the purposes of end users, but that serves to exercise control over users, to a dangerous degree.
As stated before, one of the problems is the HTTP protocol's habit of pointing you to one website, which then has full control. Part of the control comes from the fact that there is so little semantics involved in HTTP, so we end up downloading software from the very same site that delivers the data. This model is being replaced by various developments.
The solution always involves distribution of control. Just like in a democracy, where those in power still have to account for their actions, so they will be on behalf of the majority.
Not-so-tight Identities
The ARPA2 model has strong ideas about identity and how it should be used under a domain name. Indeed, when each person or organisation has its own domain name or at least user name with an abundance of aliases, then there is a good degree of control being distributed to somehwere near the user.
We have also defined a fourth phase however, which intends to grow to social structures. We call this our SocialHub phase. In this phase, we intend to open up the facilities of our hosted services for integration with others. We are keenly interested in things like attaching groups to other groups run elsewhere to form a joined service that spans domains. But we are just as interested in allowing networks such as P2P networks to spac across domains, or across user portions of services.
Where we assign a lot of value to identities in our current, second phase called IdentityHub, we are intruiged by the idea of letting go of identities, or adhering to another scheme of identities, or perhaps allowing certain new shapes of identity into our work as part of the SocialHub work to come.
The connecting concept appears to be public key crypto. Our IdentityHub facilitates key management, with an unheard-of degree of comfort for the end user, and with a refreshing level of service management for the hosting side. We explicitly enable storing key material locally, outside the control of the hosting party.
Many P2P networks use public key crypto as the cornerstone
for their online activities. So, just like we will be
supportive of X.509 and PGP for each and every ARPA2 user,
it may be possible to just generate keys for use in P2P
networks. The coupled identity may be published or not;
that is the choice of the user and their network. Along
the lines of the rest of the IdentityHub, it is at least
possible to, say, store public keys in LDAP under a domain
so it can be used to validate a user@domain.name identity,
but not all P2P networks require that.
Efficiently Hosted
Another aspect that may be of interest to uesrs of P2P networks is the ability to host the "public service" parts of these networks. The aspect of overlay routing implies a lot of communication between peers, and this may not always be desirable. Mobile network connections are relatively expensive, and having a P2P network active on a mobile device would incur a fixed initial cost as a result, no matter if there actually is any communication addressed to the user of the mobile phone.
This can be remedied by splitting the P2P functionality into a part that is hosted (either at a hosting provider or somewhere under control by the user, like at home) and a part that is mobile and runs there just for the communication of the user. This "satellite" node would simply be exempted from the social functions to network peers, which are then handled by the hosted node.
Hosting providers may in fact run one P2P node for public services, and pick out only those messages that need to be routed internally. There are so many hosting parties that this easily leads to a proper level of distribution. Of course, there should always be facilitation for users who want to run their own, and not even be dependent on the hosting provider that they pay to fulfil some of their services for them.
Adding Value through ARPA2
Even when our identity model is not neccessarily shown in a P2P network, it is still useful to realise the value that it can add. If anything, we offer ways of filtering access and validating it based on key material. An advanced form of communication can involve encryption that is only viisble to intended recipients, such as those on our ACL, or in a list of accepted keys.
Having such generous supply of keys as we have after the IdentityHub phase is complete, it should be easy for us to support encryption on P2P networks. Just to be clear; the public keys in P2P networks usually represent a node, which may be a user, but not neccessarily so.
Example Service
For a well-crafted example of a P2P network, take a look at the Inter-Planetary File System or IPFS for short. It is designed as a new and improved web service, where a local node delivers information that is retrieved from a P2P network, and held in storage and kept alive any number of participating nodes. This is a vastly different model from HTTP, which points directly to one server and demonstrate its downtime and other shortcomings very easily.
We can imagine an extension to this young system that would incorporate access control, and quite possibly store resources only in a select number of nodes, namely those that have the keys to decrypt the content. We can imagine those nodes implementing access control on behalf of the originator, as a result of their key having been included in the encryption scheme as a statement of trust.
The ARPA2 Roadmap for SocialHub
Recall our intention to support plugin services as part of the third phase by the name of ServiceHub. We should take this into account when thinking about P2P network services just as well. So, what tasks does that leave for ARPA2?
It is a bit early to answer this question here and now, but the question may well be the central one for our work on SocialHub. If you happen to work on a P2P network and are interested in discussing what you think our architecture and specifically the IdentityHub can add, then please contact us!
An early thought of the directions for an answer is that we may want to add support for connections to P2P networks where the domain-based addresses form an "anchor" that seeds data for the domain:
- P2P identities under our identity scheme
- Key management fit for P2P applications
- Access Control Lists for P2P nodes
- Sharing for groups mixed into P2P networks
- Encryption/Decryption of P2P content
- Seeding content into P2P networks
- Defining names that map to accessible hashes
- Servicing peers on behalf of endpoints
One model that might underpin this line of action would be to work "internally" on draft versions of a document, through collaboration over the Reservoir, and sharing of the final content through a publication medium like IPFS.
Go Top