Personal notes & publishing stack

The base line tool that I am looking for to anchor Community Search Engine is a multi-player personal notes & publishing stack. I have cataloged many emergent tools and tech stacks on the Community Search Engine that are now very close to what I have envisioned.

What follows are some thoughts on personal work flow and what I see needing from it.

This is a Work in Progress.

You should feel comfortable putting meeting notes, quick scratch notes, pages on their way to be published, links and a few comments, research from multiple web pages, and other material in here. It is your companion for research, progress, and evolution.

It wants to displace Apple Notes and Google Docs, and be a place where you stage short and long form social media.

It wants to be the digital place where your family group, project team, or entire small business go to find, document, and extend a growing model of useful information.

It's where you store the results from searching, browsing, or collaborative agent-based research sessions.

Personal Notes

Notes should have the following features:

• a title
• a unique identifier that is separate from the title (e.g. changing the title doesn't break links)
• wikilinks or @-mention or similar affordance to easily link to existing or stub new notes
• backlinks, where linking to a note also showcases a "backlink" when viewing the note. This creates a graph of linked notes

There are some other features like tags, aliases or transclusion that needs some more thinking.

Journal

Increasingly, the concept of author / creating / updating over time is an extremely useful anchor.

Opening notes and having date / time stamps as a default entry is good. Simple mode is one "day" note per day. A more excellent mode that also fits with shorter content publishing and sharing is block-based unique notes.

Visually, collecting notes into day / week / month chunks is one way to display aka a "log" or "work log". So a day becomes a view, but can contain multiple blocks or sub notes.

Ultimately, date & time data is metadata and can be used to create a view of any kinds of content.

Bookmarking, Clipping, and Indexing Links

Links are a primary way to remember or have quick access to "remote" content. Bookmark style for when you want to easily access the link (e.g. BC Ferries schedule), or informative / normative, like keeping a link to the restaurant in your neighbourhood that you recommend, even though you don't really visit the page.

On the other hand, there is the Clipping use case – you want to quote, annotate, or comment on remote content and keep it locally, which adds relevance for you and other readers.

Including the full content of remote links makes for a richer local index when you're querying and working with your own content. When contributed to a Community Search Engine, one gets both a community relevance graph (people who have bookmarked / clipped a link) and a sense graph, where different people have quoted / annotated / commented on the link.

Multi Player Notes

Multi-player does not necessarily mean real time collaborative editing. It starts with a single person having multiple devices where things are kept in sync, and goes from there to groups of people.

Zooming out from Personal Notes, a multi-player space can be one note that is being collaborated on, to group collections of content, which in turn forms context.

The Community Search Engine is formed by collections of multi-player notes, context, and relevance.

Permissions

The hardest part of multi player notes is permission management. "Open" collaborative notes like HedgeDoc are easy, but can suffer from spam. Security through obscurity by sharing links to hashes can work pretty well.

The "folder" model seems conceptually simplest. Make a folder, add access at that level, and then everything inside inherits that.

Sharing the same info with multiple different groups outside of a strict hierarchy is a challenge. This might mean using something like tagging to grant access. This is both a UX (what do you do in practice to share) and UI issue (how do you display shared docs or approximate GDocs permission listing).

Google Drive has ended up with this concept of "aliases", in order to have a document in multiple folders. Google Drive also complicates the folder model by allowing for different permissions inside a single folder. This means that everyone has a different view.

Related: having variable "views" might be needed along with "baked" views where everyone has the same picture. Views might in fact be something that you collect or curate and then publish to a group.

The Keyhive model, with encrypted content and capabilities delegated to individuals and groups, is the front runner of something that can work Local First and be sufficiently private, but doesn't itself have an opinionated UX, which is likely to be implemented in Patchwork.

Comments, Notifications, Subscriptions

As soon as you have multi-player, you will want concepts like comments and notifications/mentions as people collaborate.

Do you want to see all new content in all workspaces you have access to?

A follow / favourite / notify model for workspaces, favourites, or people.

I see the majority of public / social affordances here being anchored in ATProtocol identities, although the scope here is all private / permissioned data. A publishing work flow in such a way that you can privately comment or favourite rather than only in public.

Agentic Workspaces

If we envision multi-player collaboration as including agents as well as human actors, a group might contain one or more Goal Workspaces.

Publishing Stack

As well as personal, private usage, you want multi-player sharing with groups, and finally publishing.

Here I mostly mean completely public publishing such as a web page or ATProtocol post.

Permissioned access at world scale (e.g. larger than the multi-player groups who collaborate with edit / comment access) is left for a future evolution of AT Protocol Private Data.