Week 2: how to prevent an encyclosphere network from being taken over
How do we avoid our encyclosphere network being effectively taken over by Establishment forces that would try to lock it down?
keeping it decentralized from the very beginning is a great way to prevent this. if the technology simply serves the publishers and users in a functional way there won't be as much of a reason to control it since there is no commercial aspect with the content. you will have struggles between various reader implements having to promote their 'algorithmic perspective' or 'ratings-based perspective' and many end-users will just choose a 'Google' style variant and make it their primary research tool but still have some information filtered from them as with a walled garden of web2.0
perhaps it would be beneficial to run an open system via the KSF where queries are NEVER rated and ranked purely randomly or by some extremely naive and simplistic standard, so as not to editorialize the results. then you would have a base layer of just accessing the content broadly, as a sane reference point. I predict there will still become the 'FOXNews' entities of the world who strongly promote their particular bias, but at least we will have escaped the false sense of objectivity we have today with Google and other entities already doing this but without the public's general knowledge.
I continue to mull on the specifics of this idea (and this problem), but:
We try very hard to visibly compile who is referencing a work in academia. Why not in wiki's?
Encyclopedic information already generally quite strictly enforces references. Why is it when I land on a Wikipedia article (or others) that I cant see all of those other wikis (and more!) who voluntarily reference that article?
Where is the aggregation of references being displayed in a wiki reader so other authorities can be found? Their reference connectivity to the local region of topics would be immensely useful in determining a sources level of authority in a topic space in a way that (to my knowledge) is currently only accessible to search engines and large scrapping efforts.
Additionally, we have things like RSS for receiving content, where is the reverse for voluntary notification of consumption or re-broadcast of content (especially with all these bots and encyclopedists pulling from different sources) so that the producer can ALSO optionally host the reverse references (ensuring they are easily accessible while still backed up outside their ability to censor)?
Would that not almost entirely solve the problem and ensure that no one wiki doesn't also lead to greater exposure of others?
If even especially that and the identities necessary to facilitate such a reference graph were all that were decentrally stored, it would be fairly simple for any competing houses of such information to provably compare their completeness, if such graph was standardized. This would at least make being an ultimate or overly central authority in reference graph data rather difficult, and would therefor nearly ensure that all sources are given un-censorable exposure.
Of course many topics don't dully exist on 2 sources so, obscurity is perhaps a bigger issue than takeover in that sense, but if we could somehow hierarchicallize the references (already a goal in many encyclopedias, or could be done by connectivity analysis within each source) then sources sharing topic roots with any directional references between topic leafs could be used too to expose weak reverse references and latter simply and efficiently compute ranking for things that otherwise wouldn't be seen. (Like all the other wikis that reference Wikipedia and then add on top of it.)
Don't run on AWS! 😆
Decentralized is a big step. One potential threat is some big tech develops a slick reader free no ads and dominate the reader market, only to start sneaking in content controls after a couple years or market dominance.
I guess if we can assure there is always a decent ad-free reader around that would help. If it was permissively open sourced, that could be a good source of innovation
I just watched your American Thought Leaders interview and thought that it went well. Thank you for all that you're doing to help to course-correct the open Internet. Your discussion of whitelists during the interview raised some highly relevant concerns and challenges, somewhat parallel to recent discussions about DNS manipulation and hijacking concerns. I suspect that these distributed and decentralized whitelists (and meta-lists) will play a significant role in helping to manage and curate the articles that will eventually be cross-referenced in the larger stream, bringing meaningful content without complications to the reader, while simultaneously reducing incidents of co-opting and manipulation by disingenuous entities.
Who would have thought that we would (will) someday have an entire publishing infrastructure (as just one part within the larger infrastructure) focused on lists of trusted reviewers and endorsers of what is one's preferred interpretation of objective truth? This might involve lists of lists, such that one might choose to delegate their determination of trustworthiness to a distributed and decentralized shared list of trusted lists, perhaps similar to earlier web of trust implementations. This new subset of technical standards and protocols would enable one to be able to return articles that align with one's personal beliefs and predispositions. If one or more knowledge experts or endorsers in their chain of trust goes rogue (if that is the user's perception), then they could simply revoke or unsubscribe from that individual, sub-chain or even higher-level chain of trust (depending on just how bad the perceived compromise), and then optionally subscribe to new chains of trust, thereby affecting which curated articles are returned thereafter, based on those newly trusted endorsements (and perhaps other personal preferences and optional filters).
Working out how to manage, share, protect and implement these lists of trusted endorsements is going to be a big challenge, perhaps more so even than our other discussions about ensuring that DNS device resolutions aren't being blocked or poisoned. This also has even broader implications: imagine that this system is open and portable to the point of being leveraged to replace other trust delegation systems, such as (for example) product reviews on Amazon.
It seems that there are a few helpful resources to have open discussions, such as the slack channels, along with the message board (forum) posts. However, this project (really a project of projects) is a major undertaking, and I'm wondering if this needs to be broken out into different branches (which then circle back to ensure proper communications and integration), and if those collaborations might need to involve other project management tools... maybe file systems, calendars, tasks lists, idea boards, git repositories, etc. On the one hand, having a dozen different information collaboration tools might seem like a bad idea, having data going so many different directions and confusing people or getting lost; but, on the other hand, lacking different places and form factors to collaborate and organize data might prevent good ideas from being fully fleshed out in more appropriate processing and sharing environments. The old saying "when all that you have is a hammer, everything looks like a nail" comes to mind when working with a set of tools that might not be flexible enough.
If this ends up being myriad projects going many directions with many teams using many tools, then it might be wise to implement a couple of additional management and recovery strategies. I'm only referring to the architecting and engineering stage at the moment. First, keeping track of all of the different projects, teams and tools in an organized and clear manner would be helpful. Ideally this catalog, index or menu would be easy to navigate by leaders, engineers and observers, taking one to the appropriate resource for the subcomponents in question. Second, while I would hope that contributors would maintain backups of their own contributions, it might make recovery and reconstitution easier if some sort of disaster recovery plan and business continuity plan (DRP/BCP) were implemented. This of course becomes more of burdensome as more tools are added, as relates to my previous post, but if this effort ends up being a noteworthy contribution to a more resilient and open Internet, then we wouldn't want to be lacking a recovery plan (or redundancies) if an attacker or angry ISP causes all of this work to be taken offline or deleted before it could be more broadly published and implemented.