4.2 KiB

Raw Permalink Blame History

TODO

N.B. The terminology used herein is definitely a work in progress, ... along with all other aspects.

Throughout this document we will fall back on activity pub parlance, though the concepts should apply to any decentralised communication; or at least those which follow a pub/sub model.

Premises

The following premises should be true - WIP.

Per instance:
- The instance itself is an "actor"
  - Purely automated; a conglomeration of any other actors within the instance
    - potentially groups and users (human actors)
    - newswire, stories, ...? (other automated actors)
- The newswire stream is an actor (subscribe and publish)
- The stories stream is an actor (publish only)
Per user:
- Any user of the instance is actually a curator (moderator)
  - all other access is public
  - individual users are not actors (?)

Aim

The aim for the initial phase(s) is to implement the following five functions, referenced from: https://hamishcampbell.com/omn-projects-are-tools-for-you-to-change-and-challenge-the-world-we-live-and-die-in/

Link / Subscribe
- Plumb a new pipe into the network. A flow of content comes in or goes out. Each pipe can connect to any other function.
Trust / Moderate
- Flow passes through a sieve. Trusted content moves smoothly; noise gets filtered. You can send flows straight through, into holding tanks, or split them into new pipes.
Rollback
- Empty the tank, rewind a flow, or remove specific objects. Essential for correcting errors, spam, or bad data.
Edit Metadata
- Add tags or notes to the “tail” of a data object. Metadata determines how content gets sieved and aggregated. This is the backbone of news curation in the OMN.
Publish
- Add new content objects into the flow. Optionally editable. Publishing is just another pipe into the system. At the core sits the storage tank: a simple database holding all the flows.

Phase 1

The following terms are purely for differentiating between certain implementation details.

Key:

"PUBLIC":   Viewable when not logged in
"USER":     Viewable when logged in
"MOD":      Viewable when logged in with sufficient permissions

Q. (Saunders): Users being those who are, or are not involved with the output of a given instance? i.e. would they actively be publishing content on the instance, or something else?

Behaviour

'Events'
- A "federated flow" of events; an input feed of items related to the theme/topics of the MakingHistory instance. UI/X name may differ but this is short and useful for code.
- All visible tags can be a flow, we like nature metaphors so we use flow; the only thing that would not flow is the mod (not trusted) items.
- Emissary Template; based on 'inbox' ?
- PUBLIC:
  - (syn. Newswire)
  - View
    - Curated (syn. Moderated)
    - Most recent N items
    - Dynamic load earlier items on request (e.g. scroll)
- MOD:
  - (syn. Mod Flow)
  - Flagged items could end up here?
  - View
    - Uncurated (syn. Unmoderated)
    - (See PUBLIC)
  - Edit: Mark item(s) as "public"/"private"
    - Filters (hash tags, users, whole instances, ...)
    - Individual items/objects
'Stories'
- (syn. Features)
- Emissary Template(s)
  - based on ?
- PUBLIC:
  - View
    - Filter by tag ?
    - Search ?
- USER:
  - View
    - (See PUBLIC)
    - Save filter(s)
- MOD:
  - View
    - (See USER)
  - Create/Edit
    - Interactive version of 'Federated Flow' to cite/reference
      - Filters
      - Checkboxes (or equivalent) per item
'Tagflow'
- Emissary Template; based on ?
- USER:
  - View
    - Tweet-deck style dashboard of parallel tag/stream views
  - Create/Edit
    - Custom streams based on filter set
      - Boolean logic

Structure

Groups:
- Emissary groups
- Curators (syn. Moderators)
- other?
Rest looks fine, more questions :)

4.2 KiB Raw Permalink Blame History