Groups based on shared characteristics. A workgroup, territorial unit, knowledge subject, etc.

Peer networks are not planned but we can help them to grow. What is the most important? Proximity.

How do we achieve this without planning? In Lýd, groups based on shared characteristics of their members.

What kind of characteristcs? Let's see:

Any members' information can be used as nexus, createad automatically.

Nexus aren't limited to characteristics. You can create ex profeso nexus that will be shared by members, for workgroups, committees, etc.

Nexus act as sets. You can join them by sharing a flow (they are joined only from this flow's point of view), intersect them to get specialized nexus (e.g. communication team for a city), etc.

Nexus can set a mandatory flow type. For example, a Nexus for announcements can be made of simple messages.


Nexus' horitzontaliy is handled through delegation, based in trust and non-blocking decision making.

All decisions are taken through direct participation among nexus' members, unless delegation is active.

Delegation allows to take decisions in a non-blocking way. When a delegate casts a vote, it is notified to who delegated on her. This enables to cast an opposition vote (taking temporary away delegation).

Decisions must have a priority. Priority sets time limit to cast opposition votes. Different priorities and time limits must be configurable by nexus, organization or federation.


Nexus must be accessible to anyone unless legal issues exist in some groups. E.g. HHRR nexus in some countries must be only accessed by people under NDA agreements.

Nexus can be open to anonymous users (Internet's public audience). Privacy concerns are addressed next.

Any member of a nexus can know how many delegations each member have.


Members can choose how they want to be seen and what to share. This applies to their profile and presence in nexus.

For instance, an user must be able to hide all their info even nickname, masking it.

Masking nicknames should be mandatory (even mentions) when a nexus is accessed by anonymous users (public and read-only) unless participants agree on unmasking themselves (it can be on per user basis) or by configuration (overridden by users' choice).

Privacy options must be flexible enough to handle different legal requirements, including search engine indexing.

A good default would be to allow anonymous read-only access with masked nicknames to nexus and no search engine indexing allowed for users' profiles.


In volunteer-based organizations is common to find different availability levels, based on members' free time.

In any other kind of organization can be simply useful to allow members to adjust what they receive. Some members may want to keep on some nexus activities but not in its discussions.

Each member needs a different pattern and way to participate and to get information. Participation must be allowed via web and e-mail (mailing list).

Members can fit in eight participation levels:

Members can't leave a nexus based on shared characteristics but they can block it.


There are two levels of cooperation:

Nexus being sets, they can be joined and split in order to bring together and coordinate multidisciplinary groups to achieve objectives.

Nexus' relationships are not limited by organization, allowing to share and discuss in supranexus with almost equal features.

Federation is handled through flow replication (systems send new messages) and limiting delegation to same-organization members. In this way, organizations' data doesn't mix between them in convoluted ways.

Privacy settings apply in federated liquid organizations. Members can mask themselves to other organizations' members in shared flows but, at the same time, they can be unmasked to their organizations.