📚 node [[agora paper]]

Meta

By default, this paper will be built around the following:

Abstract

In this [[paper]] we describe an Agora, a [[social knowledge graph]] provisioned and maintained by a self-governing community as a commons.

The Agora [[knowledge graph]] can be defined as a hypergraph A with a set of k nodes N (entities an Agora knows about) integrated out of subnodes SN_0 .. SN_k containing subedges SE_0 .. SE_k, aggregating into edges E_0 .. E_k (semantic links between entities inferred out of known subnodes). Edges are annotated implicitly by link context and explicitly via the use of [[agora protocol]], which is extensible and tries to build on existing conventions in the [[personal knowledge management]] space.

An Agora differs from other projects in the personal knowledge space in a few ways: whereas a personal knowledge graph usually contains resources authored or collected by a single person, and a wiki usually contains resources produced by a group, an Agora contains, integrates and interlinks both personal and group resources. Whereas links in a personal knowledge graph or wiki usually have a single target, Agora links fan out by default and can be thought of as mapping to sets of resources. This is consistent with the general design principle of facilitating storage and retrieval of entity-mapped information towards removing friction from cooperation.

Building on the general principles above and a [[free software]]1 reference implementation of the underlying protocols and data, we model and detail how to implement a distributed system that provisions social knowledge services ethically and sustainably, upholding [[data sovereignty]] principles. We then analyze some of the potential applications of such a system. Finally, we shortly explore future work and social implications assuming that the Agora is run as a [[confederated]] system for the [[public good]].

Introduction

As per [[agora pkm chapter]] by default?

Background

  1. The provided [[reference Agora]] tries to remain tool, format and platform agnostic, building on general conventions common to many tools and platforms in the knowledge space for ease of integration and maximal inclusivity2 and diversity3.

⥅ node [[a-pattern-language]] pulled by user

A [[Pattern Language]]

#pull [[Patterns]]

Meta

Notes

Book outline notes

Introduction

A pattern language

  • A [[A Pattern Language]] and [[The Timeless Way of Building]] evolved in parallel and consistute two halves of a whole.

  • "The elements of this language are entities called patterns. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

  • "For convenience and clarity, each pattern has the same format."

      1. "First, there is a picture, which shows an archetypal example of that pattern."
      1. "Second, after the picture, each pattern has an introductory paragraph, which sets the context for the pattern, by explaining how it helps to complete certain larger patterns."
      • context stands out to me as an important term here
      1. "Then there are three diamonds to mark the beginning of the problem. After the diamonds there is a headline, in bold type. The headline gives the essence of the problem in one or two sentences."
      1. "After the headline comes the body of the problem."
      1. "Then, again in bold type, like the headline, is the solution - the heart of the pattern - which describes the field of physical and social relationships which are required to solve the stated problem, in the stated context. This solution is always stated in the form of an instruction - so that you know exactly what you need to do, to build the pattern."
      1. "Then, after the solution, there is a diagram, which shows the solution in the form of a diagram, with labels to indicate its main components."
      1. "After the diagram, another three diamonds, to show that the main body of the pattern is finished. And finally, after the diamonds there is a paragraph which ties the pattern to all those smaller patterns in the language, which are needed to complete this pattern, to embellish it, to fill it out."
  • "There are two essential purposes behind this format.

    • First, to present each pattern connected to other patterns, so that you grasp the collection of all 253 patterns as a whole, as a language, within which you can create an in-finite variety of combinations.
    • Second, to present the problem and solution of each pattern in such a way that you can judge it for yourself, and modify it, without losing the essence that is central to it."
  • The patterns are ordered, in descending order in terms of scale (thus one can nest the patterns)

    • "This order, which is presented as a straight linear sequence, is essential to the way the language works"
    • "Each pattern is connected to certain "larger" patterns which come above it in the language; and to certain "smaller" patterns which come below it in the language. The pattern helps to complete those larger patterns which are "above" it, and is itself completed by those smaller pat-terns which are "below" it"
    • "In short, no pattern is an isolated entity. Each pattern can exist in the world, only to the extent that is supported by other patterns: the larger patterns in which it is embedded, the patterns of the same size that surround it, and the smaller patterns which are embedded in it."
    • "This is a fundamental view of the world. It says that when you build a thing you cannot merely build that thing in isolation, but must also repair the world around it, and within it, so that the larger world at that one place becomes more coherent, and more whole; and the thing which you make takes its place in the web of na-ture, as you make it."
  • The relation between problems and solutions with individual patterns

    • "Each solution is stated in such a way that it gives the essential field of relationships needed to solve the problem, but in a very general and abstract way - so that you can solve the problem for yourself, in your own way, by adapting it to your preferences, and the local conditions at the place where you are making it."
    • "For this reason, we have tried to write each solution in a way which imposes nothing on you. It contains only those essentials which cannot be avoided if you really want to solve the problem. In this sense, we have tried, in each solution, to capture the invariant property common to all places which succeed in solving the problem."
      • Why assume that there are any invariants at all?
      • Are there problems with multiple and mutually incomensurable solutions?
  • Why they wrote the book(s)

    • "The fact is, that we have written this book as a first step in the society-wide process by which people will gradually become conscious of their own pattern languages, and work to improve them."

Summary of the language

  • "A pattern language has the structure of a network."

  • "However, when we use the network of a language, we always use it as a sequence, going through the patterns, moving always from the larger patterns to the smaller, always from the ones which create structures, to the ones which then embellish those structures, and then to those which embellish the embellishments"

  • "Towns" patterns; large scale, collective patterns

    • "We begin with that part of the language which defines a town or community. These patterns can never be "de-signed" or "built" in one fell swoop-but patient piece-meal growth, designed in such a way that every individual act is always helping to create or generate these larger global patterns, will, slowly and surely, over the years, make a community that has these global patterns in it."
  • "Buildings" patterns; inividual or small group scale

    • "These are the patterns which can be "designed" or "built"-the patterns which define the individual build-ings and the space between buildings; where we are deal-ing for the first time with patterns that are under the control of individuals or small groups of individuals, who are able to build the patterns all at once."
  • "Construction" patterns

    • "The next, and last part of the language, tells how to make a buildable building directly from this rough scheme of spaces, and tells you how to build it, in detail."

Choosing a language for your project

  • "any small sequence of patterns from this language is itself a language for a smaller part of the environment"

  • Concrete example of building a porch

  • "Rough procedure by which you can choose a language for your own project, first by taking patters from this language we have printed here, and then by adding patterns of your own."

      1. Make a copy of the master sequence of the whole language on which you can tick off the patterns which will form the sub3language for your project.
      1. Find the pattern which best describes the overall scope of the project you have in mind. This is the starting pattern for your project. Tick it.
      1. Turn to the starting pattern itself, in the book, and read it through. Notice that the other patterns men-tioned by name at the beginning and at the end, of the pattern you are reading, are also possible candidates for your language. The ones at the beginning will tend to be "larger" than your project. Don't include them, unless you have the power to help create these patterns, at least in a small way, in the world around your project. The ones at the end are "smaller." Almost all of them will be important. Tick all of them, on your list, unless you have some special reason for not wanting to include them.
      1. Now your list has some more ticks on it. Turn to the next highest pattern on the list which is ticked, and open the book to that pattern. Once again, it will lead you to other patterns. Once again, tick those which are relevant-especially the ones which are "smaller" that come at the end. As a general rule, do not tick the ones which are "larger" unless you can do something about them, concretely, in your own project.
      1. When in doubt about a pattern, don't include it. Your list can easily get too long: and if it does, it will become confusing. The list will be quite long enough, even if you only include the patterns you especially like.
      1. Keep going like this, until you have ticked all the patterns you want for your project.
      1. Now, adjust the sequence by adding your own ma-terial. If there are things you want to include in your project, but you have not been able to find patterns which correspond to them, then write them in, at an appropri-ate point in the sequence, near other patterns which are of about the same size and importance. For example, there is no pattern for a sauna. If you want to include one, write it in somewhere near BATHING ROOM ( 144) m your sequence.
      1. And of course, if you want to change any patterns, change them. There are often cases where you may have a personal version of a pattern, which is more true, or more relevant for you. In this case, you will get the most "power" over the language, and make it your own most effectively, if you write the changes in, at the appropri-ate places in the book. And, it will be most concrete of all, if you change the name of the pattern too-so that it captures your own changes clearly.
  • 3 different instructions for 3 different scales of patterns

    • "Suppose now that you have a language for your proj-ect. The way to use the language depends very much on its scale. Patterns dealing with towns can only be implemented gradually, by grass roots action; patterns for a building can be built up in your mind, and marked out on the ground; patterns for construction must be built physically, on the site. For this reason we have given three separate instructions, for these three different scales. For towns, see page 3; for buildings, see page 46 3; for construction, see page 9 35."

The poetry of the language

  • "Finally, a note of caution. This language, like English, can be a medium for prose, or a medium for poetry. The difference between prose and poetry is not that different languages are used, but that the same language is used, differently.In an ordinary English sentence, each word has one meaning, and the sentence too, has one simple meaning. In a poem, the meaning is far more dense. Each word carries several meanings; and the sentence as a whole carries an enormous density of interlocking meanings, which together illuminate the whole."
  • "The same is true for pattern languages. It is possible to make buildings by stringing together patterns, in a rather loose way. A building made like this, is an assembly of patterns. It is not dense. It is not profound. But it is also possible to put patterns together in such a way that many many patterns overlap in the same physical space: the building is very dense; it has many meanings captured in a small space; and through this density, it becomes profound."
  • "But this kind of compression is not only poetic and profound. It is not only the stuff of poems and exotic statements, but to some degree, the stuff of every English sentence. To some degree, there is compression in every single word we utter, just because each word carries the whisper of the meanings of the words it is connected to. Even "Please pass the butter, Fred" has some compression in it, because it carries overtones that lie in the con-nections of these words to all the words which came be-fore it.
  • Each of us, talking to our friends, or to our families, makes use of these compressions, which are drawn out from the connections between words which are given by the language. The more we can feel all the connections in the language, the more rich and subtle are the things we say at the most ordinary times."

Towns

Using the language

  • "We believe that the patterns presented in this section can be implemented best by piecemeal processes, where each project built or each planning decision made is sanc-tioned by the community according as it does or does not help to form certain large-scale patterns. We do not be-lieve that these large patterns, which give so much struc-ture to a town or of a neighborhood, can be created by centralized authority, or by laws, or by master plans. We believe instead that they can emerge gradually and or-ganically, almost of their own accord, if every act of building, large or small, takes on the responsibility for gradually shaping its small corner of the world to make , these larger patterns appear there."

Patterns

Buildings

Using the language

  • "We assume that, based on the instructions m "Summary of the Language," you have already constructed a sequence of patterns. We shall now go through a step-by-step procedure for building this sequence into a design."
      1. The basic instruction is this: Take the patterns in the order of the sequence, one by one, and let the form grow from the fusion of these patterns, the site, and your own instincts.
      1. It is essential to work on the site, where the project is to be built; inside the room that is to be remodeled; on the land where the building is to go up; and so forth. And as far as possible, work with the people that are actually going to use the place when it is finished: if you are the user, all the better. But, above all, work on the site, stay on the site, let the site tell you its secrets.
      1. Remember too, that the fo,;m will grow gradually as you go through the sequence, beginning as something very loose and amorphous, gradually becoming more and more complicated, more refined and more differ-entiated, more finished. Don't rush this process. Don't give the form more order than it needs to meet the pat-terns and the conditions of the site, each step of the way. In effect, as you build each pattern into the design, you will experience a single gestalt that is gradually becom-ing more and more coherent.
      1. Take one pattern at a time. Open the page to the first one and read it again. The pattern statement de-scribes the ways in which other patterns either influence this pattern, or are influenced by it. For now, this infor-mation is useful only in so far as it helps you to envision the one pattern before you, as a whole.
      1. Now, try to imagine how, on your particular site, you can establish this pattern. Stand on the site with your eyes closed. Imagine how things might be, if the pattern, as you have understood it, had suddenly sprung up there overnight. Once you have an image of how it might be, walk about the site, pacing out approximate areas, marking the walls, using string and cardboard, and putting stakes in the ground, or loose stones, to mark the important corners.
      1. Complete your thought about this pattern, before you go on to the next one. This means you must treat the pattern as an "entity"; and try to conceive of this entity, entire and whole, before you start creating any other patterns.
      1. The sequence of the language will guarantee that you will not have to make enormous changes which can-cel out your earlier decisions. Instead, the changes you make will get smaller and smaller, as you build in more and more patterns, like a series of progressive refine-ments, until you finally have a complete design.
      • [ This seems like a key point ! ]
      1. Since you are building up your design, one pattern at a time, it is essential to keep your design as fluid as possible, while you go from pattern to pattern. As you use the patterns, one after another, you will find that you keep needing to adjust your design to accommo-date new patterns. It is important that you do this in a loose and relaxed way, without getting the design more fixed than necessary, and without being afraid to make changes. The design can change as it needs to, so long as you maintain the essential relationships and charac-teristics which earlier patterns have prescribed. You will see that it is possible to keep these essentials constant, and still make minor changes in the design. As you in-clude each new pattern, you readjust the total gestalt of your design, to bring it into line with the pattern you are working on.
      1. While you are imagining how to establish one pat-tern, consider the other patterns listed with it. Some are larger. Some are smaller. For the larger ones, try to see how they can one day be present in the areas you are working on, and ask yourself how the pattern you are now building can contribute to the repair or formation of these larger patterns.
      1. For the smaller ones, make sure that your concep-tion of the main pattern will allow you to make these smaller patterns within it later. It will probably be help-ful if you try to decide roughly how you are going to build these smaller patterns in, when you come to them.
      1. Keep track of the area from the very beginning so that you are always reasonably close to something you can actually afford. We have had many experiences in which people try to design their own houses, or other buildings, and then get discouraged because the final cost is too high, and they have to go back and change it.
      1. Each time you use a pattern to differentiate the layout of your building fur-ther, keep this total area in mind, so that you do not, ever, allow yourself to go beyond your budget.
      1. Finally, make the essential points and lines which are needed to fix the pattern, on the site with bricks, or sticks or stakes. Try not to design on paper; even in the case of complicated buildings find a way to make your marks on the site.

Patterns

Construction

Using the language

  • "The patterns in this last section present a physical atti-tude to construction that works together with the kinds of buildings which the second part of the pattern language generates. These construction patterns are intended for builders-whether professional builders, or amateur owner-builders."

  • "Each pattern states a principle about structure and materials. These principles can be implemented in any number of ways when it comes time for actual building. We have tried to state various ways in which the principles can be built. But, partly because these patterns are the least developed, and partly because of the nature of building patterns, the reader will very likely have much to add to these patterns. For example, the actual materials used to implement them will vary greatly from region to region . . ."

  • "Perhaps the main thing to bear in mind, as you look over this material, is this: Our intention in this section has been to provide an alternative to the technocratic and rigid ways of building that have become the legacy of the machine age and modern architecture."

  • "The way of building described here leads to buildings that are unique and tailored to their sites. It depends on builders taking responsibility for their work; and work-ing out the details of the building as they go-mocking up entrances and windows and the dimensions of spaces, making experiments, and building directly according to the results."

  • "the patterns themselves in this section are both more concrete, and more abstract, than any other patterns in the language."

  • "They are more concrete because, with each pattern, we have always given at least one interpretation which can be built directly. For instance, with the pattern ROOT FOUNDATION, we have given one particular interpreta-tion, to show that it can be done, and also to give the reader an immediate, and practical, buildable approach to construction."

  • "Yet at the same time, they are also more abstract. The particular concrete formulation which we have given for each pattern, can also be interpreted, and remade in a thousand ways. Thus, it is also possible to take the gen-eral idea of the pattern, the idea that the foundation functions like a tree root, in the way that it anchors the building in the ground-and invent a dozen entirely dif-ferent physical systems, which all work in this funda-mental way. In this sense, these patterns are more ab-stract than any others in the book, since they have a wider range of possible interpretations."

Patterns

Resources

⥅ node [[a-rosetta-stone]] pulled by user
⥅ node [[agora-pkg-chapter]] pulled by user

Introduction

In this [[chapter]] we describe the [[Agora]], a [[protocol]] and reference [[platform]] yielding a [[knowledge commons]] provisioned by a self-governing community. This commons is bootstrapped as a [[distributed knowledge graph]] assembled from off-the-shelf components, upholding the user's [[data sovereignty]] while supporting integration with a wide range of [[tools for thought]].

The Agora as described in this article is just [[an Agora]], meaning it should be taken as a simple [[reference implementation]] of the principles delineated in this paper. Because the Agora-defining [[Agora protocol]] tries to build on common principles1 and incorporate conventions already in use at the time of writing, you will likely find that other Agoras already exist online and offline -- if not by name, then definitely in values and direction. When in doubt, the author2 likes to assume that all Agora-like entities we find will eventually be part of a greater [[confederated]] [[Agora network]]. Put another way, the reference Agora described here is just one possible seed from which an [[Agora network]] may grow.

A core aspect of the provided [[reference Agora]]3 is that its constituent [[distributed knowledge graph]] can be straightforwardly bootstrapped using just a well-defined freely-available subset of the [[internet]]. The provided software can already integrate crowdsourced sets of [[personal knowledge graphs]], [[digital gardens]], [[wikis]] and [[feeds]] of all kinds (including social), generalizing to arbitrary repositories maintained manually or via readily available [[tools for thought]] (both open and closed in nature). All supported data sources are retrieved and integrated using [[free software]], while still supporting production and editing with arbitrary tools of the users' choice.

As hinted above, the Agora is a project with multiple facets which we will try to explore in order in this paper:

The triad above fits together in a variety of ways that we will try to explore in relevant sections, but in a nutshell: [[Agora protocol]] can be used by the community while interacting with the [[Agora platform]] to provision entities, intents and services in the [[Agora commons]].

We2 then cover experiments and potential applications in the [[academic]], [[social]] and [[political]] domains assuming the availability and widespread adoption of a free [[knowledge commons]]. This is done in the form of a series of short reports and exploratory essays.

Vision

The Agora can be defined most generally as a subset of the [[internet]]4 used consciously and towards a particular purpose. Slightly less generally, as per the above, it can be seen as a platform and a protocol for provisioning and maintaining a [[commons]] (initially digital) enabling a community to efficiently define and advance their goals. Because of these broad definitions and the wide applicability of the principles detailed in this article, the background required to put this effort in context is ample and fuzzily defined at the edges.

The Agora is inspired by the work of many. Here we mention some of the core influences.

Finally, a [[caveat emptor]]: the [[reference Agora]] is highly [[idiosyncratic]]. It is [[linked]] to a pragmatic project directed towards world improvement, specifically an experiment in [[protopian thinking]] applied to [[global reform and revolution]]. This project tries to explore the full nature of the internet as it could be, using the [[tools]] at hand to work on pressing [[tasks]] as we try to optionally improve the world together. More concretely, [[Flancia]] is an exploration on the power of [[tools of thought]], including [[social media]] and more generally distributed [[writing]], to advance [[altruism]], [[rationality]] and [[loving kindness]].

Agora Commons

The heart of an Agora is the [[Agora Commons]]. It is a [[digital commons]] to start with, extending potentially to an inclusive virtual and real [[commons]] able to sustainably support its associated communities materially.

The [[Triad of Commoning]] as described in [[Free, Fair and Alive]] can be seen to apply to the [[knowledge commons]] we would like to build here, and this informs the design of the [[Agora project]]:

TODO (Diagram): [[Triad of Commoning]] as it maps to the triad of the [[Agora project]]: [[Agora Protocol]], [[Agora Platform]], [[Agora Commons]]? But the later sounds like a category mistake now. Is the Agora just recursive? :) Maybe this works better if we just mention [[intents]].

TODO (Text Structure): Making the commons a higher level section would probably clarify the structure a bit, allow me to bring in the [[Triad of Commoning]], etc. -- but maybe this has already happened, check/fix once we're in [[Google Docs]] as it'll probably be easier then.

Terminology

This project is of large scope and makes use of terminology from different fields, drawing from computer science, systems thinking and political theory. It also makes use of metaphors. To aid understanding, here we provide a short summary of key terms to follow.

  • [[Agora]]: a [[protocol]], a [[platform]], a [[commons]]. The [[noosphere]]. [[Internet]] as a tool held right.
  • [[Graph]]: the heart of the Agora. A distributed [[knowledge graph]] in particular, both explicitly and implicitly containing a variety of social graphs.
  • [[Node]]: a vertex in the knowledge graph. Maps to an [[entity]] description encoded in a [[wikilink]] or #hashtag. Maps to a mental [[context]] in an Agora user.
  • [[Subnode]]: a resource contributed by a user which the Agora will provision when queried for a variety of [[Node]] contexts. A node is a collection of subnodes.
  • [[Link]]: an annotated edge in the knowledge graph. A relationship or connection between concepts or contexts, optionally annotated. Technically you can think of it as tuple of nodes linking to each other, or more generally a set or sequence of nodes related to each other via a composite relationship (e.g. a link with annotations). The later results in a [[hypergraph]] which is what an Agora generally implements.
  • [[Garden]]: a repository of resources maintained by a user over time. (Optionally entity mapped) information contributed by a user diachronically.
  • [[Feed]]: a sequence of points in time with pointers to objects. Interesting resources as positioned in a [[timeline]]. A core [[Web]] technology that an Agora can both consume and provide.
  • [[Stoa]]: a repository of resources maintained by a group over time.
  • [[Bridge]]: a device or process connecting contexts, applying to both nodes and repositories.
  • [[Siphon]]: a bridge which exploits a gradient.
  • [[Commons]]: a [[social organism]] or [[social system]] provisioned and maintained by a community of practice for the [[common good]]. As per [[Elinor Ostrom]], [[Silke Helfrich]], [[David Bollier]], etc.

Intents

This section details intents, goals and values as they relate to the definition of an Agora on a high level.

  • The Agora is a [[project]] for the betterment of the internet, potentially leading to the betterment of the world.
  • To join an Agora, you only need to say you want to join it.
  • The Agora is a platform for [[commoning]] built on a set of public [[intents]], including declarations of [[goals]] and [[values]].
  • If you tell an Agora about a resource you care about, the Agora will try to link it and optionally save it for you.
  • The Agora as a project is positioned at the intersection of the fields of [[commoning]], [[patterning]] and [[knowledge management]].
  • The Agora is a social [[memex]].
  • The Agora is an experiment which seeks to answer the following question: what if, in the field of [[tools for thought]], [[multiplayer]] meant also [[multitool]]?

An [[Agora]] tries to meet the user where they are. As a service in the internet, you don't sign up to an Agora: you sign in. Albeit the reference Agora is based firmly on [[web 1]] principles and core [[web]] protocols and architectural styles like [[http]], [[rdf]] and [[rest]], it also includes partial implementation of [[social]] protocols like [[activitypub]] which affords it a basic level of integration with the [[Fediverse]] and Twitter[^twitter].

In the terms of the [[Knowledge Futures Group]], the [[reference Agora]] is a system that provisions an [[overlay]] (demo at https://anagora.org) querying an [[interlay]] ([[go/agora]], the [[Agora Commons]]) integrating [[repositories]] from a primarily [[git]] based [[underlay]].

With this tool the Agora community can embark on shared projects. The author, as one member of the [[Agora community]], would like to propose (offer) a series of [[projects]] as public collections of [[intents]] in the [[commons]].

[[Agora Protocol]]

Let us use [[Agora Protocol]] if we may.

This section describes a [[protocol]] for publicly defining sets of [[intents]] that can be said to define an Agora. An Agora is a public space that defines itself as such and follows an explicit variation of the Agora Protocol by [[convention]].

In text format, [[Agora Protocol]] is a series of typographical conventions that allow users to link and annotate resources regardless of the medium. Annotating here stands for encoding metadata and personal meaning in resources in a way conducive to be later decoded in an Agora-like [[context]].

If you are reading this book, you probably know Agora Protocol even before reading about it; it is meant to reflect and build on existing practices in the personal knowledge management space, like:

  • #Tags designate entities as related to the annotated resource.
  • [[Wikilinks]] designate entities as related to the annotated resource.
    • Wikilinks may be preferred when trying to encode sentences a particular typographical realization, as they seamlessly contain lossless [[unicode]] strings.

On a pragmatic level: if a person declares a public space or shared resource to be in an [[Agora]], it is in the Agora by definition. This extends to conversations in the real world.

Agora Protocol is parsed by every Agora. On interpreting a statement as an intent, an Agora may take action for the benefit of the user.

An Agora always links by default. Users can opt into automatic saving of resources, meaning storage of resources in a repository under the users' (preferred) or an Agora's control.

  • [[Optimistic linking]] is encouraged.
    • Links that lead nowhere (currently) are encouraged.
      • In an Agora, the place they lead to by default includes resources written by others.
  • [[Outlines]] or [[Agora trees]], as encoded by nested lists such as this one, might be parsed by default as declaring useful [[patterns]]7.

When interpreting the above and extensions, an Agora is liberal in what it accepts and when in doubt tries to default to being extra useful to the user -- meaning it is optimistic in association and surfaces all resources that have a claim to be associated with the context being served. For example: #CamelCase will be provided in all contexts matching [[camel case]] and all known variations, and this relationship is symmetric by default, in the sense that the user might provide either at write time and be later served matching resources in either context.

To put it simply, an Agora defines equivalence classes optimistically with good intention. Later we will discuss the hypothesis that this is an optimal default policy for a social platform.

Note that outlines plus [[linking]] seem sufficient to encode thoughts and structure of arbitrary complexity in a human readable way8. In the opinion of the author this seems sufficient to encode a [[hypergraph]] in a human friendly way, which might do away with the need for programmatically generated [[block references]]9. See [[Technical Specifications]] below for more.

Next we describe how [[Agora Protocol]] can help provision an [[Agora Platform]] which integrates pro-socially with the wider internet ecosystem, and how a community could use both to run experiments on distributed thought.

Agora Platform

This facet of the Agora is that which is closest to the realm of software. See [[Reference Agora]] and [[Technical Specifications]] below for more details.

The Agora Platform as described in this article is decentralized in nature: it is meant to be a pragmatic stopgap solution that is relatively easy to bootstrap and still able to compete with the centralized platforms that currently dominate the market in many fields and might vie for enclosing the [[knowledge commons]] soon. A fully distributed architecture might be preferable soon -- surely soon after achieving and ensuring [[knowledge independence]] for future generations. But a [[decentralized]] model like that used widely in the [[Fediverse]] has core strengths that suggest it might be a good fit for bootstrapping a [[knowledge commons]].

Federation

Individual Agora instances, initially provisioned and maintained by like-minded groups in a [[decentralized]] ([[Fediverse]] compatible) model, but tending towards a fully [[distributed]] model, are expected to federate in a greater [[Agora network]]10.

An Agora tries to be a [[repository]] of [[patterns]] in the tradition of [[Christopher Alexander]], [[Ward Cunningham]], [[David Bollier]], [[Silke Helfrich]] and [[Murray Bookchin]].

  • #meta TODO: this [[Agora protocol]] block is a MARK for 'did new writing around here in the last pass', move/delete as needed.

The Agora network is built on a federated protocol the aim of reducing friction to cross-tool cooperation and maximizing the constructiveness of forks.

Take the case in which two groups might temporarily diverge in their views to want to run separate Agoras. Ideally their instances should be able to continue to cooperate on problems and solutions for which there is enough values/ideological alignment. Persistent best effort cooperation as a default contract also maximizes the chance of re-convergence leading to a merge.

Bridges

A [[bridge]] is a process or device that can be set up to transfer resources across (previously isolated) networks, either one-time or recurringly.

Bridges are useful in that they lower friction for users to move across tools and platforms in an ecosystem, and to keep control of their data (as a bridge can be made to cross post data to a repository under the user's control, or compatible with the user's data sovereignty).

Bridges are the main tool we have to enact [[counter anti disintermediation]] and push back against [[walled gardens]].

An Agora tries to provide safe, useful bridges to the community as a public service.

Siphons

A [[siphon]] can be seen as a bridge across which [[flow]] happens efficiently after some initial [[effort]], with cost-benefit often following a Pareto-like 20-80 distribution. Many Agora siphons are specialized to perform pro social [[adversarial interoperability]].

An example siphon would be a bridge with a one-time setup cost (e.g. an end user having to set up an API key for a walled garden) but which can then be run continuously afterwards at low cost (of maintenance on behalf of the user, and of computation).

Agora Commons

An Agora is a [[knowledge commons]] provisioned and maintained by a self-governing community for [[public good]].

A [[commons]] consists, at a minimum11, of:

An [[Agora]]'s [[root repository]] is a [[seed]] for an Agora. In the provided reference Agora platform, the root is a [[git]] repository12 which contains:

  • A sources.yaml file containing a list of all repositories to be integrated into an Agora plus useful metadata.
  • A CONTRACT.md file containing a list of assertions declaring high level goals and values for the Agora.
  • A README.md file containing instructions on how to provision an Agora using the above and free software.

Intents

An Agora contains collections of [[common]] and [[personal]] intents.

By becoming part of the reference Agora, users endorse [[common]] intents by default, but can [[opt out]] of any intents perceived as problematic. In addition they can contribute personal intents which can be endorsed by other users, thus becoming [[common]].

These are sample intents of the [[author]]. They can be optionally endorsed by users of an Agora.

Literate programming

Intents in [[Agora protocol]] can be interspersed in long form writing, in which case they can act as human-readable metadata.

[[Tree structures]] with [[wikilinks]] are assumed by an Agora to carry [[Agora protocol]] by default, and may be elided or hidden when performing human-readable format conversions through [[Agora sync]].

Agora RFCs

[[Agora RFCs]] are the standard way to suggest extensions and modifications to [[Agora Protocol]].

They are meant to be cheap to write, and conducive to running experiments. RFCs are specified by nodes declaring themselves to contain an Agora RFC; a number might be provided by an Agora, but at present time there is no mechanism for allocating numbers except claiming one by pushing an RFC to it in the Agora of Flancia (or any other trusted root). Conflict resolution is done by the community of the Agora. To put it bluntly, an Agora is its own [[numbers Czar]]13.

Agora RFCs might be of varying length and detail, spanning in length from that of common IETF RFC to a tweet or toot describing a social custom to be considered by the community. RFCs which are judged promising by a community will generate and can be expounded about at greater length by the interested community and potentially worked upon in a [[Stoa]].

[[Agora Actions]]

An [[Agora Action]] is a hint left in some medium by a user of [[Agora Protocol]] for the Agora. The purpose of the hint (its nature) is defined by the action; in general, though, Agora actions can be seen as lightweight contracts between an Agora and its authors. Invocations of an action are interpreted as [[intents]].

An [[Agora Action]] is hinted by default by #tagging or [[linking]] the name of the action in resources, optionally next to nodes and URLs which the action might take as parameters.

The sections below should clarify this.

[[Go links]]

#go is an [[Agora Action]] that designates URLs as canonical or highly ranked references for nodes in which the action appears.

Go links provide an interesting base case to study in the field of provisioning and (pro socially) exploiting14 a [[knowledge commons]]. Put simply, [[go links]] are named social bookmarks -- strings of text (usually slugged, but not necessarily) associated with URLs by users in a community of practice.

[[Go links]] are a [[cognitive tool]] which was developed in [[Silicon Valley]] corporations and has the potential to spread and provide utility at internet scale. As [[cognitive artifacts]] they have a meaningful [[complementary]] component, which makes them interesting as a case study of [[Agora RFCs]] regardless of primary utility of application.

As an [[Agora action]], the contract provided by Go links is as such:

  • When you tag a URL with #go or [[go]] by placing said links previous to it in your writing, an Agora will interpret this as an intent to create a Go Link and provision and provide one for you on querying.
  • An example:
    • #go https://anagora.org
      • Means that the Agora nodes which the document I'm writing this on will be served at will, by default, provide a redirect to https://anagora.org when queried for go links.

The primary utility of Go Links, regardless of implementation details, is high. In a [[go links]] rich environment, users can depend on other users to have defined [[canonical links]] for named [[entities]]; that is, collections of specially relevant resources to the terms at hand, as shared in a [[commons]].

  • Go links provide an [[individual]] function.
    • They allow the user to associate a (usually short) string with a resource of interest, and then recall it from any computing with network access with a short deterministic flow.
    • At companies supporting [[go links]], typing go/ in the browser address bar is usually sufficient to be redirected seamlessly to the target resource.
  • Go links provide a [[social]] function at low or no additional cost.
    • The trivial extension case for them is social bookmarking; even with invidivuals (not groups) claiming go link space recall of links spreads through a community of practice.
    • Sharing documents becomes simpler by definition in a community of practice that is go links aware. Instead of locating a resource and invoking a sharing flow to share, users are able to say to each other 'go thisdoc' (meaning either go/thisdoc or go/this-doc by convention), effectively transferring a URL in spoken word very efficiently, depending only on a previously understood mechanism to resolve such links (at a well known point, ideally a [[schelling point]]).

[[Pull]]

#pull is an Agora Action. Its effect is Agora dependent but is, in essence, a form of [[transclusion]]: pull will result in a remote mental context being embedded in the current one.

#pull takes a [[node]], a [[node/heterarchy]] or a URL. Nodes might be embedded by an Agora using special in-Agora provisions. URLs might be embedded in web browsers according to X-Frame policies.

[[Push]]

#push is an Agora Action. Its effect can also be described as transclusion, but in the opposite direction: whereas Pull will transclude a remote context in the current context, Push will transclude the current context in a remote context. Push can be thought of as publishing to a [[topic]] in a PubSub system.

#push takes a [[node]], a [[node/heterarchy]] or a URL. The meaning of pushing to a node is to publish the blocks or context in the destination node; the reference Agora publishes them in a similar format to local resources, either preceding them or after them depending on configuration. The meaning of pushing to a heterarchy (or "path") is to request attaching the resource or context at a point of insertion identified by the heterarchy as an anchor, if one is found (essentially allowing to fine tune placement).

In an Agora, section headings may push the whole section to mentioned nodes.

[[Stoas]]

A resource can be declared a [[Stoa]] by tagging it as such. This marks it as a resource meant for [[cooperation]] or [[commoning]].

Applications

This section explores possible further applications in the social and knowledge spaces in the form of a series of short essays.

Provisioning meaning together with federated heterarchies

  • An Agora supports taxonomies in principle but mostly provides a set of basic tools to converge on meaning best effort through social processes based on federated [[heterarchies]].
  • [[Agora trees]], meaning by default [[outliner mode]] text with [[wikilinks]], hint at sections containing [[Agora Protocol]].
  • [[Agora RFCs]] allow a distributed Agora community to extend the base [[Agora Protocol]] for more efficient [[commoning]] using atomic proposals.
  • TODO: (Details on an [[open source algorithm]] for ranking and filtering based on the above go here.)
  • TODO: (Details on eventual [[convergence]] as a phenomenon to be studied.)

An Agora tries to solve all of these based on social signals contributed to the commons:

  • [[taxonomies]]
    • [[heterarchies]], as represented by [[agora trees]] and [[path/like/queries]], can be reinforced by the Agora as more users hint at them.
    • Hypothesis: this can do away with the need for fixed taxonomies or category systems, and the associated upkeep cost (and potentially gatekeeping) that comes with them.
  • [[equivalence classes]]
    • If [[x]] pulls [[y]] and [[y]] pulls [[x]], then [[x]] ~ [[y]], meaning [[x]] and [[y]] converge in some useful context. This is true in particular if more than one user has contributed these signals.
  • [[ranking]]
    • It is well known15 that links provide a strong signal for relevant and notability in graph like systems.
    • #uprank is an explicit Agora Protocol action that takes a subnode or user and hints at an intent to rank them more highly than the current resource.
    • #pull can be used as a ranking hint as well: if [[x]] pulls [[y]], [[y]] is more likely to be roughly as relevant as [[x]] in any contexts in which [[x]] is relevant.

Collaborative world building

  • We seek to provision and maintain a distributed knowledge graph tailored specifically to the goal of solving problems: those of its users and society at large.
  • Its users, as a cooperative group, are promped to take a naive but rational and constructive approach to problem solving by default:
    • For each problem in the set P of all problems:
      • Describe it as thoroughly as possible.
      • Maintain a set of known and supported possible solutions, S(P).
    • For each solution in S(P):
      • Describe it thoroughly as an algorithm, a dependency graph or both.
      • Maintain a set of resources (people, time, attention, wealth) needed to implement it, R(S(P)).
    • Individual users can also declare their views on the state of the world explicitly: they define which subsets of P, S and R they agree with, in the sense that they believe they are feasible, true, interesting.
      • Users that agree on their defined subsets can then efficiently collaborate on solutions as they become available by pooling of resources.
  • Assuming the existence of such a graph we apply some good old recursivity and bootstrap an Agora with the problem of building itself.
    • That is, we are tasked with solving the problem of building a system that allows participating users and entities to collaborate optimally in the face of adversity (such as biases and irrationality), maybe only assuming good intent.

Node Club

Once a week or a month (depending on the time of the year), the [[Agora community]] proposes a set of nodes to be provisioned loosely concurrently over the next period -- meaning nodes to be contributed to individually, at roughly the same time.

Thank you to [[neil]] and the [[agora community]]!

Educational technology

Solving coordination problems

Flow problems

  • #pull [[liquid democracy]] [[network flow]]
  • We seek to bootstrap a [[Universal Basic Income]] experiment using an Agora with a set of simple rules:
    • If you consider yourself under-privileged, you sign up to receive an income.
    • If you consider yourself over-privileged, you sign up to donate an income.
    • Incomes are recurring donations for a set number of months.
  • Optional [[virality rule]]: the person receiving the income should elect to forward e.g. 10% of the sum received to someone less privileged than them.
    • The virality rule both pushes network growth and constructively exploits wealth inequality and asymmetry of information: an under-privileged person is closer in the world to a more severely under-privileged person than the initial donor, so can more efficiently allocate the resources. This also empowers under-privileged people to also make ethical decisions.
  • [[Flancia Collective]] runs experiments in this field using an [[Agora]].

Market composition and regulation

A [[knowledge commons]] may be conducive to tackling the issue of regulating markets responsibly. A commons can essentially embed a federated network of ethical markets; the community of commoners can agree on the definition of such network and the rules which they which to enforce on transactions through the interface.

Commons can be seen to be well positioned to operate as meta-markets in a world (and internet) where markets, originally distributed in nature, have been coopted by corporations.

Application stores worldwide, the dominant bookseller in many countries -- all work as centralized markets that can impose high trading fees because of the lack of competition. It seems evident we must avoid this same scenario from reoccurring in the [[Tools for Thought]] space; a federated network is needed. But corporate profit driven interests are likely already dreaming of taking hold of the space; how can we stop them?

Simple, maybe: we must retreat up a level and build a healthy integration layer that pushes back against early efforts to build walled gardens around tools and their strong communities. We must build bridges out of walled gardens and into the commons and there provide services to users of a wide range of tools, and enable ethical corporations to use these bridges to also provide these services.

Technical specifications

Agora Protocol example

The blocks that follow, and others in the current text in the same [[console typeface]], are a self-documenting demonstration of text based [[Agora Protocol]].

  • #push [[agora protocol]]
    • (Push can be used for writing child blocks to a remote context, as if broadcasting to a [[pubsub]] topic.)
    • a [[protocol]].
      • Based on lightweight conventions conducive to [[knowledge federation]] of supported [[data formats]] as described below.
      • [[plain text]] as layer 0 (bootstrapping).
        • What the literate world already runs on: just plain old human language in full [[unicode]].
        • Note that indented bulleted lists are efficient while encoding trees, [[heterarchies]].
      • [[wikilinks]], #hashtags and other link conventions and annotation as part of layer 1.
      • Layer 2 being defined, the same as refinements to other layers, as [[extensions]].
        • If you are a member of an Agora, you can propose extensions to Agora Protocol by contributing to [[Agora RFCs]].
        • This should be sufficient to bootstrap a [[governance layer]] defined by each [[Agora]].
        • #pull [[agora rfcs]]
        • (Pull instructs an Agora to incorporate a remote context into the current context, e.g. [[transclude]] or provision below.)

Data format

  • Layer 0: [[plain text]].
    • Plain text is ubiquituous.
    • It is not only a common standard for all tools in the knowledge space, which simplifies interoperability; it is a common standard for thought as shown by thousands of years of preserved culture.
    • It can trivially encode outlines.
      • It can be made to encode trees, like in this example.
      • Indented bulleted lists designate a useful [[heterarchy]].
    • It generalizes to binary data.
      • It can be made to encode arbitrary data via application of uuencode or other encoding conventions.
  • Layer 1: [[markup]] and conventions for cross-referencing and linking.
    • Markdown, org mode, HTML or other rich markups building on top of plain text belong to this layer.
    • [[wikilinks]] and #hashtags seem like sensible cross-format extensions for semantic linking.
    • Markdown plus [[wikilinks]] is the default Agora layer 1 format.
    • More generally, this is an [[inline metadata]] layer. The above are just relatively unobstrusive generally available implicit standards that inline well.
  • Layer 3: JSON, EDN, RDF, protobufs.
    • In general, data exchange formats.
    • The Agora reference implementation currently provides JSON and RDF endpoints.

Graph definition

The Agora [[knowledge graph]] can be defined as a hypergraph A with a set of k nodes N ([[entities]] an Agora knows about) integrated out of subnodes SN_0 .. SN_k, each containing subedges SE_0 .. SE_k, aggregating into edges E_0 .. E_k (semantic links between entities inferred from known subnodes). Edges are annotated implicitly by link context and explicitly via the use of [[agora protocol]] affordances, which is extensible and tries to build on existing conventions in the [[personal knowledge management]] space.

An Agora differs from other projects in the personal knowledge space in a few ways: whereas a personal knowledge graph usually contains resources authored or collected by a single person, and a wiki usually contains resources produced by a group, an Agora contains, integrates and interlinks both personal and group resources. Whereas links in a personal knowledge graph or wiki usually have a single target, Agora links fan out by default and can be thought of as queries mapping to sets of resources. This is consistent with a general design principle of facilitating storage and retrieval of entity-mapped information with a view toward removing friction from agreement and cooperation.

Building on these general principles and a [[free software]]3 reference implementation of the underlying protocols and data, we model and detail how to implement a distributed system that provisions social knowledge services ethically and sustainably with a focus on upholding [[data sovereignty]] principles. We then analyze some of the potential applications of such a system. Finally, we shortly explore future work and implications assuming that the Agora network is run as a [[confederated]] system for the [[public good]].

  • Being built around a [[knowledge graph]], an Agora can be defined as a set of vertices or nodes N (each mapping to an entity in a knowledge base) and edges E (each mapping to a relationship between entities, annotated by context).
    • An Agora [[node]] is a collection; it contains the set of all known resources about (or related to) the entity described by the node id, defaulting to its name as an arbitrary length unicode string.
      • (But potentially overridden or extended with provided metadata and annotations.)
      • In this paper each such resource attached to node N is known as a subnode N_s.
    • Note that because links can be annotated by context (as they can be considered to be by nearby #tags and [[wikilinks]]), an Agora graph can be said to be a hypergraph 16.

Reference implementation

  • This section covers details on the work-in-progress reference software implementation built on the principles described above, developed as [[free software]] and run as [[public service]].
  • The provided [[reference Agora]] is designed to be a minimum viable cooperative platform that integrates and complements [[personal knowledge graphs]] in particular and, more generally, any writing done with a [[social stance]].
  • Its guiding architectural principle being to build as much as possible on already existing conventions common to as many tools and platforms as it is possible with the aim to achieve maximal inclusivity and diversity.

Here we cover some details of the provided free and open source reference Agora which provides a minimum viable implementation of the [[underlay]], [[interlay]], and [[overlay]] components of a [[distributed knowledge graph]]17.

  • The reference Agora stands out from other projects in the [[knowledge graph]] space in a few ways:
    • Whereas links in a personal knowledge graph or wiki usually have a single target (a particular note or page), Agora links fan out by default; targets can be thought of [[collections]] of resources.
    • While a personal knowledge graph usually contains resources and links authored or collected by a single person, and a wiki usually contains resources provisioned by a group in (a priori) a shared voice, an Agora tries to integrate and interlink both personal and group resources while preserving distinct voices18.
    • As of the time of writing, some personal knowledge graph tools are exploring collaborative editing in format- and platform-specific ways. In contrast to this, the reference Agora described in this chapter tries to be tool, format and platform agnostic to maximize interoperability and data exchange and provide utility to users of many tools and systems. This is achieved by targeting a minimum viable set of cross-tool conventions.

Architecture

agora architecture

  • The reference Agora is a simple distributed architecture based on off the shelf components.
    • [[agora root]] is a git repository containing the Agora definition, meaning a base [[contract]] which sets the tone and high level goals of the Agora, and a list of data sources to be recurringly integrated.
    • [[agora bridge]] is a git repository containing connectors and importers for supported data sources.
      • User controlled [[git]] repositories are the default data source.
    • [[agora server]] provides a UI supporting querying and composition and [[json]], [[rss]], [[rdf]] endpoints.

Data ownership model

The [[Agora platform]], although strictly rooted in [[web 1]] principles in its reference implementation as of the time of writing, is based on a strictly distributed model: by default users are entities that inform an Agora of repositories they want to contribute to the [[commons]]. As such, an Agora is trivially distributed in the sense that all data required to bootstrap it is hosted independently by users at independent locations19.

  • Users can contribute [[repositories]] to an Agora.
    • To do so, they publish their resources to a repository they control and then they let an Agora know of their intention to integrate, a desired username and their agreement with an Agora's contract.
    • [[git]] repositories are the default data source, with other repository providers ([[http]], [[ipfs]], [[drive]], [[dropbox]]) to follow.
  • Users can contribute individual [[resources]] to an Agora.
    • As of the time of writing they can interact with an Agora system account (i.e. bot) in supported platforms like [[twitter]] and [[mastodon]] while indicating nodes they want to attach to using a Layer 1 convention.
    • (Soon they will be able to submit this information directly on the [[agora server]] provided interface.)
  • Whenever a user signals [[opt in]] to remote writing (bridging, siphoning, cross posting), [[an Agora]] does its best to guarantee user data ownership.
    • By default, an Agora will not store data for the user if it the user has not signaled a strong enough intent to write full data. Instead, an Agora will try to [[link]] to resources only in matching contexts, allowing users to recover resources without meddling in data management (see [[go links]] study case).
    • Whenever it does write data, an Agora will try to provision a separate repository per user and try to turn data management into a user's concern at the user's earliest convenience.
      • To put it another way, an Agora actively tries actively to own no data, preferring instead to act as a temporary [[data steward]] of the users' repositories.
      • When an Agora sets up a repository for the user, as in the case in which the user requests to write without having previously indicated their repositories, the Agora will try to set up repositories in such a way that turn-key full access can then be given over to the user on demand.
      • Inasmuch the user depends on services associated with an Agora for repository hosting, an Agora tries to trees repositories as instances of [[pods]] in the [[Solid]]20 sense.

Endpoints

This section triers to summarize the endpoints that [[Agora server]] provides and plans to provide.

Agoras can define mappings from these to URL schemes generalizing to isomorphic REST-like APIs using agora.yaml21.

Entity resolution

  • GET /<context> -> by default the same as /node/<context>, might be overridden with a more particularly useful context
  • GET /node/<node> -> entity resolution, node can be percent-encoded
  • GET /nodes -> lists known entities in canonical form
  • GET /@<user> -> provides details about a user and the [[subnodes]] in their repositories.
  • GET /users -> lists users
  • GET /search?q=<query> -> generally redirects to /node/<node>?q=<query> with node being a maximally useful context while preserving fidelity with the percent-encoded query string

Feeds

  • GET /feed/@<user>
  • GET /feed/<node>
  • GET /feed/journals
  • GET /feed/journals/@<user>

Actions

  • GET /go/<node>
  • GET /go/<node1>/<node2>

References

Thanks and farewell

The author would like to thank [[Flancia Collective]], the [[Agora community]], and the [[Fellowship of the Link]]: for your inspiration, interest, guidance.

To my [[friends]]: for your ongoing love and support.

To you: for reading.

To all the Agora builders and maintainers through history, including those of the motivating historical [[poleis]] and those who will build Agoras for the peaceful cities and countries of the future.

Finally, some friendly parting words: if you don't like this [[Agora]], rest assured that's perfectly alright -- it is early stage. The [[Agora of Flancia]] is [[open source]]; these projects have [[Apache]] and [[Creative Commons]] licenses respectively. Please consider improving them!

  1. both commonsense and related to instances of [[commoning]].

  2. Eduardo Ivanec, a.k.a. 'flancian', representing [[Flancia Collective]] and the [[Agora community]].

  3. The provided [[reference Agora]] tries to remain tool, format and platform agnostic, building on general conventions common to many tools and platforms in the knowledge space for ease of integration and maximal inclusivity22 and diversity23.

  4. Or [[Web]]? See literature for most common term, likely web due to ties to the [[semantic web]] if nothing else.

  5. As per Matuschak and Nielsen (2022), Kenneth Iverson seems to be the source of the currently dominant blanket term "[[tools for thought]]" -- although I can report he didn't use it in his seminal paper, preferring instead "[[tools of thought]]". I use these two interchangeably, maybe preferring the latter due to it giving thought agency.

  6. As of the time of writing the reference Agora can't publish to fedwiki, but can import fedwikis into the Agora Commons as repositories.

  7. An Agora is a repository of [[patterns]] and its design owes a lot to [[Christopher Alexander]], [[Ward Cunningham]], [[David Bollier]], [[Silke Helfrich]] and the [[commoning]] community.

  8. indentation is sufficient

  9. Hypothesis: [[Block References]] are suboptimal as [[cognitive devices]] due to being [[competitive]], whereas user generated IDs and encoded structure can be [[complementary]].

  10. An Agora is part of the Fediverse.

  11. https://logicmag.io/commons/singular-plural/ (or https://anagora.org/go/singular+plural as of the time of writing.)

  12. https://github.com/flancian/agora (or https://anagora.org/go/agora as of the time of writing.)

  13. https://www.rfc-editor.org/rfc/rfc8700.html#name-the-rfc-management-and-edit

  14. TODO: there's probably a better term for this in [[Free, Fair and Alive]].

  15. TODO: find paper or good up to date reference.

  16. "Stephen Wolfram likes them." -- see for example https://www.wolframphysics.org/technical-introduction/.

  17. https://www.knowledgefutures.org/

  18. it is an expression of the [[pattern]] [[chorus of voices]].

  19. as of the time of writing, GitHub is the most popular git host, but not by much (TODO: percentage goes here). This is likely suboptimal as it undermines the claim of the resulting [[knowledge commons]] of being truly [[distributed]], and can be seen as an instance of the (anti-)pattern [[Anti Disintermediation]].

  20. https://en.wikipedia.org/wiki/Solid_(web_decentralization_project)

  21. or TOML?

pull color="#b51f08"> <title>500 Internal Error wtf.
<link rel="stylesheet" href="https://doc.anagora.org/css/center.css"> <button class="pull-url" value="https://doc.anagora.org/css/center.css">">pull</button>
<div class="container-fluid text-center">
    <div class="vertical-center-row">
        <h1>500 Internal Error <small>wtf.</small></h1>
    </div>
</div>
⥅ node [[agora-pkm-chapter]] pulled by user
⥅ node [[agora-slides]] pulled by user
pull color="#b51f08"> <title>500 Internal Error wtf.
<link rel="stylesheet" href="https://doc.anagora.org/css/center.css"> <button class="pull-url" value="https://doc.anagora.org/css/center.css">">pull</button>
<div class="container-fluid text-center">
    <div class="vertical-center-row">
        <h1>500 Internal Error <small>wtf.</small></h1>
    </div>
</div>
⥅ node [[i-am-a-strange-loop]] pulled by user
  • "I think, therefore I think I am. It may turn out that the "I" which Descartes discovered is actually the demon he was trying to guard against. It is the I that fools itself into thinking that it exists. It is Berkeley's mind observing itself and therefore causing itself to exist. It is God observing himself — the universe becoming self-aware. A strange loop, lifting itself up by it's boot straps."
⥅ node [[node]] pulled by user

Node

what each note in the [[agora]] is called

⥅ node [[pattern]] pulled by user

pattern

⥅ node [[the-expanding-circle]] pulled by user

The Expanding Circle

I've been meaning to take notes on [[the expanding circle]] but I haven't found the time to do it. I didn't take notes here as I was reading it as I did much of the reading at night, in my [[e reader]].

I'll now try to write my impressions here in free form as I can and as I reference it through the [[agora]].

This is a hugely influential book for me but, wait for this, I only finished it on [[2021-12-21]] (I sometimes take unreasonably long to finishing things; it is one of my noticeable traits. In this case I left it at essentially 90% of the way through for no good reason but inefficiencies when scheduling it for reading.)

But because this book describes a proposition that I already believed, it felt valuable to me already. I considered it core to my thinking even if I hadn't finished it yet. It is a good [[distillation]] of the ideas of [[effective altruism]], or the ideas that led to the movement and represent, IMHO, its reasonable core.

  • The central tenet of the book is that over the course of human history, people have expanded the circle of beings whose interests they are willing to value similarly to their own. Originally that circle would have been self, family and tribe, but over time it grew to encompass all other humans.[

I wonder if this relates to [[dunbar's number]]

pull color="#b51f08"> <title>500 Internal Error wtf.
<link rel="stylesheet" href="https://doc.anagora.org/css/center.css"> <button class="pull-url" value="https://doc.anagora.org/css/center.css">">pull</button>
<div class="container-fluid text-center">
    <div class="vertical-center-row">
        <h1>500 Internal Error <small>wtf.</small></h1>
    </div>
</div>
📖 stoas
⥱ context