Forum

A Framework Discuss...
 
Notifications
Clear all

A Framework Discussion


rich
Posts: 4
 rich
Topic starter
(@rich)
New Member
Joined: 1 month ago

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.

12 Replies
Mutchler
Posts: 34
(@mutchler)
Eminent Member
Joined: 2 months ago

First of all I’m retired after 40+ year in technology, the last 25 as an IT manager of a hospital.  I’m not afraid of technology, but don’t pretend to know it all.  I’ve done some programming (using machine language), before and after the PCs.  I’m pretty familiar with hosts, servers, networking, internet (BTW I know why it’s called “the cloud”) and most devices that connect to the internet.

I don’t understand some of the terms you used here, but I think I got the concept.  My first question has to do with the first amendment.

Is or should everyone be allowed in every town square?  Years ago a “Company Town” in West Virginia or Kentucky was ordered by the Supreme Court to allow a religious person to hand out flyers.  Even though the town was privately owned.  That’s because they allowed the public to enter the town.  So, I’m assuming if there is no charge to enter a town square, the first amendment applies.  Which I guess should apply to Twitter.

If everyone is allowed to enter, should I have to listen to every soap box, or only the ones I choose to?  Assuming the first amendment applies, is there a limit to what I can say from my soap box?  What about something that is against “the law”?

Now, if I am charged to enter a town square (not open to the public), does the first amendment apply?

Reply
rich
Posts: 4
 rich
Topic starter
(@rich)
New Member
Joined: 1 month ago

Your point on The Twit and 1st amendment is well taken. I don't know why such rules that apply to public spaces have not been enforced against the big social platforms. My guess is that they well might be once the right case reaches the Supreme court (at least from a U.S.-centric pov). 

My view for this framework is that the host of a Town Square could manage it by whatever rules they wished. They could allow anyone to register and post, or they might only allow users to register if they meet some other criteria.  A Town Square might be created for an actual town, requiring registrants to validate their address through some means external to the Soap Box ID (like NextDoor.com does today). It's conceivable that someone could put up their very own micro-blogging Town Square server with only their own profile allowed to post. The common API's and Identity would allow users to "subscribe" to that Town Square and "follow" that poster and even reply to posts (if the Town Square allows it).  

Any given Town Square could be moderated under their own rules. If someone puts up a Town Square for discussions of Star Wars, they my delete posts or threads that are off-topic. It's up to them and their "community".  I can imagine that I might have my Soap Box ID as a citizen of several different Town Squares. On one I might discuss politics, on another I could post about photography, while on still another I might be discussing open-source software development. Anyone could follow and engage with me on one or all of those Town Squares via their client software and see just those posts of mine they are interested in, but they can be assured that "@rich" on each of those Town Squares is the same me. 

Much like socials today, I don't think you would be forced to read the content of any poster you don't want to. The various clients could offer controls for only retrieving the posts and conversations which you explicitly follow. There might be common API's for searching by hashtags, but any given Town Square might have that enabled or disabled. A Town Square might offer a "recommended" or "trending" feed of posts, but it would be up to you and your client software whether you utilize those features. 

 

Reply
2 Replies
Mutchler
(@mutchler)
Joined: 2 months ago

Eminent Member
Posts: 34

@rich I think part of the problem is currently in Twitter we follow (and hear) what @rich says.  Instead of just hearing what he says about Star Wars.  Currently I’ll hear what he says about fishing also, even if I’m not interested!  Maybe we should be following the “soapbox” that @rich is in.  Maybe I’m a “citizen” of the “Star Trek” town square, but am only interested in the “Next Generation” soapbox.  

Maybe when I follow, I can select a person, town square or soapbox.

Reply
rich
 rich
(@rich)
Joined: 1 month ago

New Member
Posts: 4

@mutchler I have thought about the idea of "following" a Soap Box ID across independent Town Squares.  Since an ID is independent of the Town Square hosts that validate against the decentralized identity system, some other discovery mechanism would have to be designed in order to locate all the Town Squares on which any particular ID posts. Some options might be:

  • Some standard query API for Town Squares to check if an ID is a Citizen of that Town Square, or maybe a "feed" to advertise their list of Citizens' ID's
  • Directories could be created to track on which Town Squares individual posters are Citizens. Client software could simultaneously post a users Citizen list to this directory as well as query the directory to update the users list ID's he/she "follows" 
  • Perhaps as part of the Citizen header information that accompanies a post on a Town Square (or maybe that could be queried about a Citizen) would be a list of links to the other Town Squares on which that user posts. 

These are just a few mechanisms I came up with off the top of my head. There certainly may be other/better ways we could facilitate this type of feature that we could come up with.

Reply
atmchuck
Posts: 7
(@atmchuck)
Active Member
Joined: 1 month ago

@rich, that is a nice job laying out the parts. As your ideas evolve here, how do you account for the sharing of ideas in this ecosystem that some some might not agree? And I'm thinking from two perspectives here.

  1. Internally, or within the ecosystem - I see this as being more easily solved. I can see who I want, I can block who I want, and I can say what I want. Only existing law can block what is said.
  2. Externally, or on the web - This becomes more difficult, as the ecosystem you describe would need to have "built-in" some safeguards that allow for the publication of content despite the opinions held by those in control of upstream provider resources. How would Parler have survived, if it were built on the model you describe? If we are not thinking about this now, then I'm concerned we are leaving out an important component.
Reply
1 Reply
rich
 rich
(@rich)
Joined: 1 month ago

New Member
Posts: 4

@atmchuck

Parler® was built on AWS, which wasn't necessarily a mistake for a startup. But the fact that AWS booted them was a problem for them because their AWS code base and infrastructure doesn't easily port to any other cloud provider. Parler is now re-building on more free-speech friendly infrastructure, which will take time. If they are smart, they will build it based on something like Docker and Kubernetes that will easily port to other cloud providers. They also had single apps on the two major app stores. Easy to block by conspiring and coordinating (racketeering?) large corporations.  But let's imagine what this scenario would mean under an infrastructure I describe:

Imagine that a microblogging platform (Town Square) could be installed on AWS by simply clicking on an EC3 image. It takes only a few minutes to set up an AWS account and maybe a few more to install and get an image running. With a common API, all of them are accessible from any client software built on the same standard. None of the these Town Squares has violated any of AWS's ToS. If the "Parler Town Square" is kicked off AWS using a false charge, influential Citizens of "Parler Town Square" could continue posting on any of the other Town Squares or even spend 15min and create their own. Sure, AWS could block the development and use of "Town Square generic microblogging software", but that would be like banning Wordpress.  It would have a chilling affect on their platform if developers and maintainers of other open source AWS images realize their hard work could be stifled and taken away at any time for no logical reason.

If the host, or Town Square, software has many ports that are all built on a standard or compatible data schemas and API's, then the "Parler Town Square" could easily take one of its regular backups and install on Firebase, Azure, IBM Cloud, etc.  If there is a Docker port, they could resurrect their service almost anywhere in the world within hours (provided they were smart enough to separate their service provider and domain registrar). 

Now also imagine that the "Parler Town Square" didn't only have their own phone app on the app stores. With common API's and importable libraries, there might have been many apps that could be viewing posts there, but not necessarily. Since these apps only access Town Squares to which the app user subscribes, the apps themselves can't be accused of violating any app store ToS. To ban them all would be like banning a browser because of sites the user of the app might visit. With common libraries available to import into Swift, et al., there could be dozens of apps available to continue viewing content on Town Squares - even if those Town Squares have to move to new hosting or platform providers. If there were Wordpress plugins, cPanel packages, Squarespace templates, etc., then there could be dozens of web based clients, as well. Heck, you could get a US$9/mo shared hosting package on A2 or HostGator and have your very own private Town Square client running in minutes.

The upstream provider issue is one that has to be settled in the courts and via legislation. There are several legal challenges currently making their way up to the Supreme Court. Some of these cases are taking the view that if section 230 protects "platforms" from public suit based on user content, then it also protects them from upstream provider censorship / retaliation based on that same consumer content. There are also challenges to the hosting providers' claims of 230 protection i.e. The Twit might be protected by 230, but The Twit's upstream service provider might not be based on their ToS and behavior. These are obviously U.S. centric points of view. Hosting providers in other jurisdictions have their own rules to operate under. But given the amount of services hosting hackers, pr0n, etc., I don't think it would be difficult to find a provider/platform that doesn't give a rat's a$$ about "Big Tech's" virtue signaling. 

 

Reply
atmchuck
Posts: 7
(@atmchuck)
Active Member
Joined: 1 month ago

Thanks for the detail, @rich, that helps me! 😉 What I like about what you're saying here is that this would all be built on an existing protocol (https), and not reinventing a new one (IPFS, etc.). As much as I like what I understand about IPFS, it can easily be shut down. By using https/web services, this whole thing is hiding in plain sight.

Reply
3 Replies
BladeMcCool
(@blademccool)
Joined: 2 months ago

Active Member
Posts: 15

@atmchuck how can IPFS be easily shut down?

Reply
atmchuck
(@atmchuck)
Joined: 1 month ago

Active Member
Posts: 7

@blademccool I understood that a new protocol like IPFS could be easily excluded or shut down by browser manufacturers or service providers, mostly because it could be easily identified/filtered by port. That said, I am still learning about IPFS, so I'd love to be educated more on this. Please help me understand about how IPFS would be fault tolerant in that way. Also, know that I'm rooting for any/all technology that will help people be able to communicate freely. You mention below that you are working on something related to IPFS. I'll take a look to see what I understand!

Reply
BladeMcCool
(@blademccool)
Joined: 2 months ago

Active Member
Posts: 15

@atmchuck my view is that browser manufacturers cannot stop someone from running arbitrary javascript code like the js-ipfs library. They also can't stop people from making their browser talk to a service that connects them to an IPFS node over http. Governments the world over have demonstrated their impotence when it comes to trying to stop people from using p2p protocols like bittorrent in ways they don't like. As far as I understand it, the more people using IPFS nodes to pin a given piece of popular content, the more nodes an attacker would have to take down -- much like bittorrent swarm peers. From what I've come to understand about IPFS it is fairly robust and fault tolerant to get the data if there is redundancy for the requested data within the network. I'll admit i need to experiment more to get a better feel for the true level of fault tolerance. But spinning up new IPFS nodes to join the swarm seems really easy. Maybe the default bootstrap servers are a small attack surface that could interfere with the network - however i also understand its easy to just add more servers to that list

Reply
BladeMcCool
Posts: 15
(@blademccool)
Active Member
Joined: 2 months ago

I've been working on something that is based on similar ideas. Not a perfect match but i think it is neato.

https://github.com/BladeMcCool/IPFS-Social-Graph

Reply
1 Reply
BladeMcCool
(@blademccool)
Joined: 2 months ago

Active Member
Posts: 15

Identity: RSA keys generated in the browser that can be used to sign messages, and even be used to publish IPNS updates in IPFS.

Hosts/Platforms: With what i have here, a "host" would likely be a server running ciddag with its own private IPFS node connected to the swarm. It can serve UI to any requesters, and allow authorized profileIds to perform operations through it. My conceptualization of the 'town square' is a big interlinking data structure dumped into IPFS and added to by the various participants/profiles. Thus anyone could create a host/client ui to render the content in whatever way they wanted, to allow whoever to post through it, to manage RSA keys on behalf of their users or make them do it themselves in client JS code. Your view of this "town square" will depend on which profiles you are interested in following and crawling post history of and how the service you are viewing it through decides to present it to you.

Client applications: Basically what you have described should be possible with the architecture I imagine.

Reply
Share: