Week 2: The compone...
Clear all

Week 2: The components of the encyclosphere

5 Posts
4 Users
Larry Sanger
Posts: 27
Member Admin
Topic starter

What should the main software components of the encyclosphere be?

Posted : 13/09/2021 6:06 pm
Posts: 14
Member Admin


MediaWiki & DocuWiki (majority of all wikis)

RSS / activitypub

JSON / XML APIs & compilers

Elasticsearch / Logstash / Kibana



Bittorrent / Webtorrent



Posted : 14/09/2021 12:42 am
Larry Sanger
Posts: 27
Member Admin
Topic starter

Well, a list of the technical tools used to build the software isn't what I meant. I meant the higher-level software.

Basically, in any communication network, there are the nodes, the content and user accounts that reside at the nodes, there is the communication between the nodes. So it stands to reason that we need the following components:

I. Authoring tools

Authoring software: This already exists in many forms (all encyclopedias already have this functionality), but the feature that is essential to the Encyclosphere is the ability to post articles (preferably, cryptographically "signed" articles) to the Encyclosphere, i.e., to make them available in one way or another. Some Encyclosphere-specific features just need to be added to existing authoring tools, CMSs like WordPress, Drupal, and Joomla, as well as wikis, especially MediaWiki. 

User registration: More of an important subcomponent than a stand-alone component. This doesn't merely establish identities within a particular encyclopedia (or authoring or rating system), it ties ("signs") any uploading, authoring, editing, deleting, and rating activity to the identity. This way, a person who contributes an article via his own blog is credited across the Encyclosphere as being the same author as the same person who writes for Britannica. We have been talking about adapting DID:Web to use with Minifeed as well as the Encyclosphere.

Article/content feed and/or submission feature: Another subcomponent, mostly, but this is the main new component that needs to be added to existing CMSs (MediaWiki and WordPress are the top priorities).

II. Aggregation and storage tools

Feed aggregators and crawlers: Software that aggregates many feeds and makes the results available in various ways to reader apps. Rather than passively receiving pushed data from an aggregator, crawlers go out to hunt for and fetch it.

Storage tools: More of a subcomponent of either content submission tools or of aggregators, this would make a permanent backup of content submitted to the network on such decentralized storage tools as BitTorrent and IPFS.

III. Search and reading tools

Encyclopedia readers: These would be the encyclosphere analogue to blogosphere feed/news readers. Encyclosphere readers would combine search engines with delivery of open content articles, or links to proprietary articles. Some might actually feature payment systems for encyclopedias.

Encyclopedia search engines: Straightforward. Already possible in various ways, but aggregation of standardized data would make them an order of magnitude more useful. Would probably be a component of an encyclopedia reader.

Posted : 14/09/2021 9:24 pm
hampson reacted
Posts: 7
Active Member

Higher-level ready-to-run preexisting open source software should be utilized instead of reinventing the wheel wherever possible. If it is determined that some of the desired functionality is new and not present in existing software, then at that point the first preference would be to fork an existing product's git repository and expand upon it (if allowed), and the second preference would be to create an entirely new product. One of the challenges with expanding a preexisting product is that the software developer needs to first come to understand the design and internal workings of the product, before the developer can add new features to that product. Some developers might opt to start from scratch with creating a new product, one that they come to understand as it is being created, rather than first having to understand what other developers were thinking when they created their preexisting product, before a new feature could be added to that preexisting product. The first option is ideal, but might involve higher overhead level of effort, whereas the second option is more divergent and messy, but might involve lower effort.

Posted : 27/09/2021 2:57 am
Posts: 2
New Member

What if there was the publishing-sphere, an abstract internet-space where everything published goes, and the reference-publishing-sphere is a specific subsphere (ie encyclosphere) where everything reference-published goes. The publishing-sphere could contain both the blogosphere and the encyclosphere as subspheres, even minifeed (in a way).

Then what if the publishing-sphere is just a sub-sphere of the internet public-sphere. At the public-sphere level, the idea of a user-person arises pretty naturally. I think you should be able to make any amount of user-accounts between the user-person and the public-sphere.

User-accounts would be the main fundamental unit in all of the ‘spheres. In the Encyclosphere, user-accounts can have authorship smoothly attributed to them, and references to their authored work can be tied to user-accounts (or user-persons).

Content on the reference-publishing-sphere would be reference content. Reference content, a subcategory of content, is content composed with reference/citation. User-owners could have their authorship credited on content very easily, and all their work would link to them.

Phrasing it like this has a lot of opportunity for inoperability, but I do not have the expertise to make a formal structural opinion.

Publishing on the encyclosphere involves publishing uploading/connecting to the 'sphere's standard. Publishing software would format your document into the appropriate category so all work can be processed in a standard way by aggregators.

Posted : 13/12/2021 11:18 pm