It is our job to make sure that the Hypermedia protocol is robust, documented, coherent, efficient, and scalable in many dimensions. We must also make the daemon an incredibly powerful, portable, and reliable reference implementation.

We struggle with definitions in our language, and we have under-documented the permanent data. Lets create a formal definition language for permanent data, which will also produce very concrete definitions for the language on our team. These will be publicly listed with nice presentation, and they will be integrated into our protocol documentation.

The raw data blobs (eg, so-called "permanent data") should reference the definitions they are using, over IPFS or similar, so that the protocol becomes rather self-documenting.

There should be a mechanism to extend the Hypermedia protocol for additional applications, extending the Formal Definitions.

We have too many types of APIs. GRPc, libp2p messages, REST, tRPC, electron.

We need events, that allow the daemon to trigger behaviors in the JS server and client. Currently the client does polling only, which is slow and wastes resources.

We should commit to a single protocol, defined by a schema, make sure it has realtime and GraphQL-like functionality, and widespread industry support. Then adopt uniformly across all of our services: Desktop, Web, Host, Pay

If possible, the Modular and Formal Definitions should be encoded by our API definition.

The API ergonomics should improved, simplified if possible, and brought in-line with the Definitions

The API should be publicly exposed over standardized interfaces, including the web browsers who are interfacing with the server.

It should be possible to harden so that it can be limited to authorized users, ensuring they are only accessing the acceptable content. This will be vital for our multi-tenant use case, where domains should limit the content. This will also be important for moderation, so that only authorized users can see content which is blocked/banned/deleted.

Once we have formal definitions, the daemon and clients should use automated tools to ensure our code is working with the data and API correctly. It should provide robust validation, type safety, and error handling. If our code encounters new data schemas and APIs, it should handle it gracefully.

Keep track of what peers are acting in good faith, and what services+content they provide.

This may be exposed to the user via an API, who can keep track of peers manually with tags, overrides, and other tools.

If an account chooses to identify as a peer (like we do with web servers), the account trust can be associated with the peer. This allows you to send protected or private data to this peer, or trust it to perform certain services.

This will unify our approach of delegating to certain centralized hypermedia services. By default, the application will trust us for services like Gateway, Host, and Pay. But this is configurable.

Users should have a GUI and APIs to access this, leveraging their web-of-trust to manage the peers who they trust.

The protocol should be as efficient as possible to sync only the data thats needed.

You can ask peers (who you really trust) to search its index with a wide variety of the existing methods, or you can push objects to them

Near-Realtime interactions: the protocol should support immediate syncing when possible/allowed

Change-based Entities should support Snapshots, so you don't necessarily have to crawl back the full history to see the latest state.

We should be able to keep track of the data use on a node, and provide tools to help users manage their data.

This includes a configurable disk garbage collector, analytics of resource use, and tools to limit resource use. Allow users to inspect and evacuate the index

Peer nodes should support varied modes. Many of these could be enabled together:

Once our API is improved, we should properly version it, document it, and open it up as part of the protocol.

We should bake in the following as first-class citizens of the protocol: Hosting, Payments, Donations, Pay-Walling

Our modular protocol allows you to build support for arbitrary Products and Services (like Analytics or LLMs)

A user wants to have multiple devices, with their private information securely syncing between them. For example drafts and favorites.

SHM users should be able to message each-other securely and privately.

We should create a roadmap to v1 of the protocol, even if its rough. At a minimum, we should seriously consider the ideas in this document.

Make sure we support native phone apps, as first-class citizens alongside the web and desktop app.

All the middle end data should be baked into the daemon, or saved into Hypermedia format.

Take "Settings" for example, this could be a private entity/resource which is configured to not share, garbage collect, or sync to any other devices. This allows us to share the formal definition/schema for all application data.

One way to clean up our system is to allow JS to own the keys and all signing. We do this on web and we plan to do it on mobile. We could re-use the same JS key+signing code inside the desktop app. This way, the go team doesn't have to maintain two types of nodes + APIs- one which owns+uses keys and another which does not.

We could release the JS client library which allow our clients to delegate most functionality to the API, while retaining their keys and privacy.

Be careful about what we store in plain-text on the user's machine.