Hello Decentralizers,
I am a software engineer with over 25 years’ experience on everything from mainframes to iPhone apps. I found this site via a link from Sharyl’s news page. I have been lurking and reading all these great ideas here and a general framework is starting to coalesce in my head, mostly prompted by Larry’s discussion of the need for common API’s or interface descriptors. Let me lay this idea out and maybe we can start discussions around it.
Parts and Pieces
I think we need to break the issue down into digestible chunks. This will allow discussions between people with different expertise to tackle the different pieces. I will discuss this in terms of micro blogging, but it really could be applied to other types of “social” platforms, as well. The three parts of the system are basically an identity system, client applications, and hosts. These three parts would interact with each other through a common set of API’s or interface descriptors.
Identity:
A decentralized identification and authentication system (possibly based on blockchain technology) that will keep users’ “personas”. It would hold basic information like a user id or screen name and a public key to identify the user and validate signed posts, replies, or comments on any of the hosts using this identification system. In terms of the micro blog, let’s call this a “Soap Box ID”. A real person might have one or more Soap Box ID. There may be different levels of ID’s such as anonymous and verified ID’s.
Hosts / Platforms:
We will call this a “Town Square”. It is the actual micro blogging and commenting platform. It will conform to the common API’s and utilize the Soap Box ID’s to authenticate and validate its members or “Citizens”. My vision is that there would be open-source ports of Town Square software for almost any platform (AWS, Firebase, cPanel, WordPress, etc.). Installing and setting up a Town Square host should be as easy as running a package installer. A Soap Box ID could register as a Citizen of one or more Town Squares and be verified to be the same poster across all Town Squares. i.e. @BobJenkins would be the same @BobJenkins in every Town Square.
Client Applications:
Client applications might be in the form of websites, phone apps, desktop software, web apps, or anything else. These applications would allow a user to log in to the client, authenticating against the identification system using their Soap Box ID. Using the common API’s or interface descriptors, these apps would allow the user to “subscribe” to any Town Square of which the user is a Citizen. Kind of in the same way that a podcasting app subscribes to as many podcasts as you want. The client app would aggregate the feeds from all of the subscribed Town Squares and allow the user to sort or view them all in many ways. Again, I envision Cocoa Pod libraries, Homebrew packages, WordPress plugins, etc. Creating such a client should be so easy that they would be many and varied.
Features and Functions
Identification System:
- The Identity system would be distributed or copied across many hosts to ensure its ubiquity and resilience.
- A “full host” would service API’s for verification and validation functions of the Soap Box ID’s. These API’s would be used by both clients and hosts.
- There might be a nominal fee (maybe US$0.99) to create a new ID. Maybe a bit more to create a “verified” ID. A revenue sharing scheme would incentivize the creation and maintenance of many “full hosts”.
- A “full host” might offer faster API services to hosts or clients for a monthly fee.
- A “full host” might offer API’s for clients and hosts to register/create new Soap Box ID’s through their own software in return for further revenue share and to entice such hosts or clients to use their identity services.
- A common set of identity API’s would allow a host or client to easily switch to a new identity provider, configure automatic backup providers, or even “round-robin” between providers for robustness and fail-over.
Hosts:
- Each Town Square can be governed by its own Terms of Service. They can delete posts, block users, require “verified” accounts, etc. A user can always take their Soap Box ID to another Town Square.
- Hosts would keep a partial list of the identity system locally (their own registered users) in order to validate signatures of posts, comments, and replies. They would accept updates to this information (push/pull?) from the identity “full host” against which they validate.
- Each Town Square can determine its own features. Such features might be communicated to subscribing clients via header attributes such as imagesHosted, externalImageLinksAllowed, videoHosted, embeddedVideoLinksAllowed, clientRegistrationAllowed and so on.
- Hosts could be further incentivized by embedding ads into their feeds. Perhaps standard ad network plugins would be available.
Clients:
- Client software features can be as varied or limited as the creator desires. For example, there is nothing to stop a Town Square host from creating a web client or phone app and limiting their app to interfacing only with their own Town Square, creating a structure similar to most current micro blogging platforms. They could conceivably instantiate their own identity system from the open source and run a single copy on their own server making their platform completely self-contained.
- Clients could allow subscription to any number of Town Squares and aggregate the various feeds and offer various sorting options to the user.
- Clients might allow grouping of subscriptions into Town Square Categories.
- Clients could allow posting of new posts to a single Town Square or cross-posting to a group of Town Squares. The post signature would identify cross-posted duplicates to any client in the case that the post is received from multiple subscriptions.
- Clients could provide ubiquitous or on-demand signature validation of posts in the feed.
- Web clients could be incentivized by displaying ads alongside the feeds like traditional web sites do today.
- App clients could be incentivized by charging for their app, they could display in-app advertisements, or they could receive revenue from in-app purchases for unlocking additional features.
Further Discussion
I know there are holes all over this framework right now, but I am confident that these holes can be filled by discussions between persons more knowledgeable in those specific areas than myself. Some basic areas that we might begin discussions around could be:
- What are the basic attributes of a Soap Box ID vs what extended attributes might be requested / required by specific Town Squares to which the user becomes a Citizen?
- What core features/functions must be provided by hosts and clients vs features/functions which are optional, but provided for in the API definitions?
- What is the core database schema required for a host? i.e. What are the core required attributes of a post, reply, comment, or anything else required by a micro blogging architecture? Can a host or host software package extend these attributes in their own database for their own purposes? Do we provide a mechanism in the API’s for communicating such extended attributes between clients and hosts, such as a serialized field if key/value pairs?
- Could we create open-source software to act as a “Bullhorn” to allow Soap Box ID’s to announce changes in where they post? Maybe open-source software to for directories where users can post links to the Town Squares on which they post? Maybe client software can use these directories to allow users to “follow” posters across different Town Squares?
In Summary
The goal with this general framework is not to create a system in which posts, documents, videos, images live forever without an ability to be taken down. For sure, any specific Town Square could conceivably be canceled by its hosting provider or platform. In such a case, those posts would be gone (although a real-time backup feed pops into mind to allow the Town Square to be easily revived on another platform). The goal is that many hundreds of Town Squares could exist at any given time on any given platform or hosting service. Any entity attempting to silence or censor speech would have to address each one individually or else attempt to do something akin to banning Wordpress as a whole.
Likewise, it is conceivable that there could be many client apps in existence and more such clients could easily pop up. I think any app platform would find it difficult to ban such apps since all they do is allow the user to subscribe to various Town Squares. Banning them would be akin to banning a browser. And since clients could also be web sites and web apps, there would always be alternatives to using “approved” app store apps.
The identity system is the most likely target of any entity trying to censor specific voices. This is why it is the one piece that must be decentralized and widely distributed. Blockchain lends itself to this type of structure (and there are several blockchain based identity frameworks being worked on). Creating financial incentives for “full hosts” all over the world would ensure the continued existence of this piece. It would also create a lot of backlash if an authoritarian attempted to take down a system whose only function was to validate user identities in the same way that Google and Facebook are trying to make their user id’s ubiquitous across web sites and service.