Vision for Hypermedia Content Management

This rough proposal is a work in progress and resembles a broad vision for managing content and syncing. Any feedback is welcome. The scope is large and can be implemented across many projects.

Overview

With the following primitives, users can have complete control over their hypermedia landscape: Connect, Discover, Load, Subscribe, Block

This document describes the most important user tasks with regard to content management, but there is a lot more that is possible and will be eventually needed by advanced users.

Connect

Connection info is private and is kept on your device. Different devices for the same user may have other connection settings

Manage Connections

For each Account and GroupSite, you can specify if you want to connect or not. If you have enabled connection, the Account or GroupSite may be called a "Connection" (regardless of your current connection status)

The disconnect button terminates your current connection, if any, and disables further connection to this Account or SiteGroup.

Connect All

There is a button to connect to all known Accounts, with a warning that this may slow down your network

Incompatible Connections

If a peer uses a different TestNet, or if the peer is only an IPFS peer, they will not show up in the connection list

If a Connection uses a different protocol version, they will be greyed out and you can see a notice that explains “they are using newer/older protocol version N”.

Connection Feedback

We should have visibility about connection status: for example, display how many peers we have and how many we are currently trying to connect to.

Discover

A way to find content that you might be interested in, before you have loaded or subscribed to it. You will query peers for their indexes and keep this in memory, without persistence. The content you discover is not private but your Connections can theoretically see what you are attempting to discover.

After clicking on the initial ”discover”, we will show how many peers your are querying, and give you shortcuts to connect to more peers and therefore expand your Discovery radius.

Content that you discover is not signed. In addition to the IDs, the peer will report basic info such as title, alias, photo and author. You will temporarily trust the integrity of the content (until you Load it). The UI can grey out the discovered content so it is apparent that it is less

Entity Discovery

There are Discover buttons under Groups, Contacts, and Documents to discover more Entities that you may want to Load or Subscribe to.

There could be another workflow for discovering Comments

Searching Discovery

In the quick-switcher you can click “Discover” to search your peers for the typed query string

Citation Discovery

You can discover citations/backlinks for content, asking your peers if they have content that links to something

Discovery Metadata

When the app shows discovered content, it should be possible to see what peer(s) have provided it. If the same content is shown by multiple peers, we can prioritize it.

Load

If you click on some content that you don’t have (for example, after Discovering it), you will request it from your peers. Content will be stored on your node after it has been downloaded. If another account Subscribes to all of your content, they can effectively see what you have Loaded.

We will only load the content that is required for the user’s given request. So we will not load linked entities that are not showing up on the screen. For example:

•

When you Load a Document, we Load all Accounts who contributed, but not other Variant Authors

•

When you Load a group, we Load the front page Doc, but not Group content Docs

•

When you Load a Document, we Load all embeds, but not linked content

If Loading fails because no peers have it, we will fall back on the DHT to find a peer who has it, add a Connection to the relevant peer, and Load from them.

The Load workflow will be used by the web gateway.

On a regular basis we will Load the latest "Subscribed" content from connected peers. (Better yet, we can tell our Connections what content we want and they can push that content to us immediately.)

Here we cover the basic user tasks, but we also should support unsubscribe workflows and maybe even bulk Subscription workflows.

Subscriptions are public and for each account you can see what they subscribe to. There may be a button to “subscribe all” if you want to subscribe to everything that an Account subscribes to.

Subscribe to Account

When Subscribing to an Account, you will add them as a Connection, and you will get all the content they have signed, plus the reference materials.

Subscription settings:

•

Checkbox (default true): Reference material: Subscribes to all Entities that is referenced by any signed content from this Account.

•

Checkbox (default false): Download all: get all content this user has on their node

•

Checkbox (default false): Block Sync: block everything they have blocked

Subscribe to Document

When you Subscribe to a Document, you will specify a variant to Subscribe to (by default, the owner variant)

Subscription Settings

•

Checkbox (default true): Subscribe to Reference material - so you can subscribe to other Documents and Entities that are referenced by this Document

•

Checkbox (default true): Subscribe to Comments - so you will get all comments that target the Document Versions within your subscription

•

Checkbox (default false): Subscribe to all Variants

Subscribe to Group

Subscribes to the Group and all content within it (the Group Variant of these Docs). If the Group has a Site, you will add that as a Connection

Subscription Settings:

•

Checkbox: Subscribe to referenced content

There would be a shortcut that allows you to Subscribe to all editors of the Group

You can subscribe to a SiteGroup via URL. The onboarding process facilitates your first Group Subscription, to give you an entry point to all content and Accounts on the network.

Block

These workflows allow users to delete content and avoid similar content in the future.

Blocking will override all Subscriptions, hide content during Discovery, and you cannot Load blocked content (if you try, an error appears saying you have blocked it, giving you a button to unblock)

If you unblock something, you can sync it again. There should be some UI for managing your blocked content. Because the content will be deleted, there could be a message that the user inputs along with the block, to explain why they don't like it.

When another user Subscribes to your Account with block sync enabled, they will download your list of Blocks and therefore can see what content you have blocked.

Block account

Delete all content from an account, don’t re-sync it, disconnect and never re-connect.

Block document

Delete doc and all changes, don’t re-sync, same for comments under this doc

Block group

Delete this group and don’t re-sync it

Block group+content

Block this group and all Documents we see within it

Block group+content+authors

Same as "Block group+content", also block all Accounts who are members of the group

Block comment

Deletes one or more comments and does not re-sync them

Rabbit Holes

•

Users may wonder “why do I have this content” and the app should be able to explain, for example, that it was loaded on X date, or show who you downloaded it from

•

Same for Subscriptions. Because of recursive Subscriptions users may wonder why they are subscribed to something

•

Same for explaining to the user why content is Blocked

•

We should have a private history for all Subscriptions, Loads, and Blocks. So you can review when and how you arrived at the current settings.

•

Fine-grained control: users may want to decide who they discover from, or selectively unsubscribe from some things which are referenced from other things

•

Workflow to avoid sync of large files, or delete them without Blocking (to reduce storage use). They can be loaded again on-demand with IPFS

•

Enhanced privacy, so that Subscriptions, Blocks, or Loaded content is kept a secret from your Connections and therefore will not be synced to them if they subscribe

•

There are lots of edge cases with multiple devices- should you attempt to connect to all devices of a Connection's account? How should we handle cases where settings are different on each node?

•

Connections may be made from another peer who decides to connect to you, so you need a mechanism to prioritize initialization of connections and allow blocking connections