Multigraphs, federation, an attempt to describe Athens' far future

[Limezy]

Disclaimer : anything above is only my own proposal and vision. I'm not a member of Athens team and I'll just express what I think could be a great for Athens' future. And I write this here as a starter for conversation, as I'm deeply convinced that collaboration will make ideas even greater

Intro

https://athens-research.ghost.io/athens-1-9m-seed-round-led-by-caffeinated-capital/

We raised $1.9M to invest in our vision of building a second brain and a second internet using knowledge graphs and bidirectional links.

Athens team has been talking a lot about collective memex, second web... But what exactly are these in practice ? How could knowledge graphs and bidirectional links help create a "second internet" ?

I believe that this is through multigraphs and federation

• Multigraphs, so that you can keep the power of a knowledge graph but still be able to split your knowledge into several distinct graphs ("first internet" analogy would be intranet and local hyperlinks. You keep the link power by being able to link from one computer / server to another, but stuff is still a little bit organized as one server could be seen as an autonomous entity)
• Federation, so that you can connect to graphs that are not yours and benefit from a multi-user, multi-connected knowledge network ("first internet" analogy would be the web and internet hyperlinks, where you'll be able to interconnect your own connected stuff with others' to create a giant network)

Assumptions for my proposal

Hosting architecture

For my proposal below, I've assumed that it exists a big Athens federated network

• The Athens network is made of multiple servers
• Each server hosts multiple users
• Each user owns multiple graphs
• Each graph hosts multiple pages
• Each page hosts multiple blocks

With this in mind, the current Athens backend could be seen as a mono-user, mono-graph server prototype.
With this also in mind, in a near future, the Athens Research SaaS paid subscription model may give you access to multiple graphs as a user of the main Athens Research server (I'll assume below that it's hosted on athensresearch.com)

For the sake of simplicity, I'll assume that when using Athens locally, it's running on a local server that has one user.

Links syntax

For my proposal I'll also assume a syntax for page links. That syntax, obviously, covers all the nesting layers above :
[[server/user/graph/page]]
When using shorter links, the "prefix" will be assumed (more on that below)

• [[user/graph/page]] : here, the server is assumed
• [[graph/page]] : server and user are assumed
• [[page]] : server, user and graph are assumed

Obviously, the software would provide with a lot of options to avoid users typing the full page links and keep a seamless user experience.

By assuming by default the common prefix

• If I'm Limezy working alone in my local Personal graph, the system will always assume local/Limezy/Personal as the default prefix for any [[Page]] link
• If I'm Limezy and have two Pro / Personal graphs on my athensresearch.com Saas subscription, the system will always assume athensresearch.com/Limezy as the default prefix for any page link. I can then refer to any [[Pro/Page]] or [[Personal/Page]]

By allowing to set up a default prefix

• If I'm Limezy and have two Pro / Personal graphs on my athensresearch.com Saas subscription + I contribute to the athensresarch.com/Athens/Documentation graph, I can set athensresearch.com/Limezy to be my default.
• When that's the case, if I link [[Pro/Page]] the system will see it as [[athensresearch.com/Limezy/Pro/Page]], and if I want to refer to a page from Athens' documentation, I can link to [[Athens/Documentation/Page]]

By using autocompletion or guess work

• If I'm Limezy and have two Pro / Personal graphs on my athensresearch.com Saas subscription + I contribute to the athensresarch.com/Athens/Documentation graph, I can set athensresearch.com/Limezy to be my default. When that's the case, if I link [[Pro/Page]] the system will see it as [[athensresearch.com/Limezy/Pro/Page]].
• But if I link to [[Documentation/Page]], AND I don't have any Documentation graph underathensresearch.com/Limezy/Documentation, then the system will know that I'm linking to athensresearch.com/Athens/Documentation

By providing a possibility to alias the remote users or graphs

• If I'm the same Limezy as above, I can always alias the "namespace" Athensdoc to athensresearch.com/Athens/Documentation link, and when I will link to [[Athensdoc/Page]] it will link to [[athensresearch.com/Athens/Documentation/Page]]

Access and modification rights

Access and modification rights level

So now that we have an architecture of servers, users, graphs and page, how should the access and modification rights be defined ?
We want some privacy, we want some collaboration...
First of all, I believe that access rights management should be at page level.

• If it's implemented at block level, I feel it will be a nightmare to have such small granulosity
• If it's implemented at graph level, we may end up with a lot of very small graphs

Theory

It seems to me that each page should feature (vocabulary to polish) :

• An access setting :
  • Private - only accessible and linkable from the same graph
  • Shared - accessible and linkable from federated graphs or users (see below)
  • Published - accessible and linkable from the whole Athens network
• A modification setting
  • Read only
  • Committable (any modification will trigger a pull request - see below)
  • Writable (users that have access can freely write)

Ideally, we should be able to setup different modification settings for different access levels
Some by default settings for new pages should be setup at graph level

Examples

• Shared + Committable page is similar to Github
• Published + Committable page is similar to Wikipedia, Reddit, Twitter...
• Shared + Writable page is similar to Google Docs or Etherpads
• Published + Read only is similar to Wordpress or any blog
• Shared + Read only is similar to a Facebook post

So is this just similar to the "first internet"? No, because it has backlinks ! 🚀

Athens Federation

Users or Graph federation

Just like within ActivityPub decentralized network, we should build a federation network of graphs

• I could request some Users or Graphs to federate with me
• It's a two-way and trust relationship and won't be done until the other User accepts the federation bound
• Once we are federated, I will have access to all his Shared or Published pages from the federated network
• Backlinks from all Shared or Published pages will pop out in the "Federated Linked References"
• Obviously, all graphs from one same user are federated by default

Users or Graph follow

Just like within ActivityPub decentralized network, I can also follow a user or a graph

• It's a one-way non trust relationship - doesn't need acknowledgement (even though that user can follow me back)
• Once I follow a user or a graph, I'll have access to all his Published pages
• Backlinks from all Published pages will pop out in the "Followed Linked References"
• A user that didn't publish any page yet can't be followed

Examples

A blog mechanism within Athens federated network

• I follow Jeff user from athensresearch.com/Jeff
• He has his blog under a graph (Published + Read only) at athensresearch.com/Jeff/Blog
• He publishes a new page [[athensresearch.com/Jeff/Blog/Federation is awesome with Athens]]
• Even if I don't regularly go and check his blog, suppose I have myself a [[Federation]] page, I'll see his blog post popping out on my "Followed Unlinked References" backlinks block

A Wikipedia mechanism within Athens federated network

• Athens documentation is hosted on athensresearch.com/Athens/Documentation graph
• The Documentation graph is Published + Committable
• I find a typo in the [[athensresearch.com/Athens/Documentation/About page]]
• I change a few blocks, then I pull request my modifications (see below)
• The user Athens, owner of the graph, can accept my modifications

Page or Graph operations within the federation (vocabulary to be polished)

Clone a Page (or a Graph)

• Any page I have access to can be cloned to one of my graphs
• This will basically copy the whole page to my own graph, or to a graph I have write access to
• The page would be strictly cloned, so there would be no change in the links or block references
• Clone + Merge : if a page with the same name already exists in my local graph, both would be merged (after a merge request dialog)

Translate a Page (or a Graph)

• Same as clone, but links will be translated to local links
• If I clone the page [[athensresearch.com/Jeff/Blog/Federation]] to my local/Limezy/Personal graph, then if that page had a link inside to [[athensresearch.com/Jeff/Blog/Hello]] it would be changed automatically to [[local/Limezy/Personal/Hello]]
• Mechanism for block quotes to be defined. Most probably same behaviour as when a reference is deleted : you'll have a small warning sign, you can click on it, and either search for a new block to quote or convert to text

Push or pull request a page to a committable one

• Either a committable page I've edited on the fly
• Either a committable page I've cloned then edited on my graph than that I push back

Athens Federation interconnexion with Fediverse

• ActivityPub is so powerful that we can think of a millions use cases...
• Each time a guy I follow on Mastodon will make a new toot, it will create a new block on a dedicated page. Same for Peertube with videos, Pixelfed with pictures...
• Each time I create a new block on a dedicated page, it will create a new toot on my Mastodon account. Same for Peertube with videos, Pixelfed with pictures...

Outro

I've tried to give a few hints about what I think the future Athens could be !
There are obviously a tremendous number of challenges ahead on the technical part... Not even mentioning the safety side of things... But without that it wouldn't be fun !
The beauty is that federated multigraph instances could reproduce nearly all the current internet usage... BUT with backlinks. And backlinks are the backbone of knowledge management fun. I'll try to give here a few examples where I'll try to highlight why and how backlinks are a deal changer.

Blog with comments

• My blog is a published graph
• It features a mix of read only pages (the blog entries) and committable pages (the comments that I can approve)
• For each blog post (read only), I embed a dedicated comments page (committable) in the last block
• Some of my blog posts could also be just shares of other blogs, using [[otherserver/otheruser/blog/post]]
• Backlinks are great, because
  • For the blog owner, he'll be able to see who referenced his blog post (not all referenced, referenced among his federated friends' shared pages, or among the whole Athens network's published pages). For example, if it's another blog, even from someone he doesn't know, he will see the backlink pop out. We could imagine dedicated notifications and so on...
  • For the blog reader, he'll be able to see who referenced that same blog post among his friends, followed, or discover new blogs / thinker that have linked to the blog post they are currently reading

Bible (or any other text) study

• Some provider shares a bible text online on a published or shared + read only page
• I study it and make some block quotes, references...
• When I go to the provider's page again, I'll see a number next to the block I've quoted
• That number not only includes my own block references, but also the ones from my friends / followed / published pages among the Athens network (or even, that would be cool, Fediverse)
• When my friend goes to that same exact page, his number will be different because he doesn't have the same federated friends / followed and so on
• When I click on the number I can filter and discover shared or published pages from a particular user that did some piece of thinking on that particular bible block / verse

TODOs as a team and live transparency with client

• Within a company using Athens, each team member shares his TODOs that are cumulated through a filtered TODO backlink
• A filtered page featuring all the TODOs for a particular project can be published and shared with the client

And so on !
Tell me what you think, I'll definitely be happy to discuss the future of Athens !

[BradKML]

Self-hosting is important, and that being able to fuse information graphs are good.