Web Commenting Redirect + Resource IDs

This week I've done a few additional experiments trying to use the Channel Messaging API with the idea of getting rid of the redirect flow when commenting on the web. In the end it didn't work. Apparently Safari is only able to give access to cross-origin cookies, but not other state like IndexedDB. I then started hashing out ideas on how to implement cross-origin signing of comments by using key delegations. The main concern I have is that I don't want the additional keys start sprawling around with full power over the account, like the agent keys we currently use for hyper.media. I want session keys to be scoped for a particular target. I haven't finished cross-origin signing, because  brought up the fact that addressing comments is a pressing concern right now, which I agree with. Exposing comment URLs is surprisingly tricky, because we need to change the format of a comment blob a little bit, to include additional information.

Pay Server

In Stripe, the url field is mandatory when onboarding an account. That's why all the hassle with the URL field in the demo. Actually, the site url in our system is also paramount so i though to link both urls

Profiles, Contacts and Detached Blocks

Profiles Contacts Detached Blocks

Improve resize performance on Web

Here's the video of how many elements were updating when the panels resize: and here is the performance metric of the same interaction before and now this is the state after the optimization: the main issue was that we were calculating the panel width on every resize and setting the value to a state. this was causing almost all the components to re-render. now we are not setting the value to a state bot to a ref, and only re-rendering when needed. This was a small change, hard to find but with a huge improvement!

Web Site Importing

We have built a new web site importing experience that will download a whole website and publish it as a directory in your Seed Hypermedia site. Currently this is oriented towards Wordpress websites, but we can add support for other sites as needed. So please reach out on Discord if you need help importing your site. To get started click the "Import.." button in the document options dropdown, and select "Import Web Site" Then input a URL and wait for the web download (scraping) to complete. The last step allows you to confirm which account will be committing the information. Finally your site will be imported. The importer currently supports:

Seed Website

Demo Brief

Daemon pushing algorithm

This document tries to enumerate blobs that need to be synced in order to render a proper document

I have created a new guide for custom domain please review!

   

Paid Content

Problem Solution Behavior Downsides Scope

Cross-Site Signing

Problem Solution In the original window where the comment draft exists, there is an iframe which has loaded the identity provider hyper.media/hm/embed/auth. Internally it is polling the indexeddb for the containing origin's abilities. When they change, they are and communicated via postmessage so the publisher knows what sort of content can be signed in the iframe. When the comment is submitted, air.com passes in the unsigned comment blob to the identity provider iframe (again, via postmessage). The identity provider iframe will make sure the ability is present and valid. Then will sign it. It will pass the signed comment back to the air.com who requested it. At this point the signed comment needs to be saved to at least one server, and it can be sent to air.com or hyper.media, or both, whoever is willing to distribute it. For now, air.com will be the one responsible for saving and distributing the comment blob, which will result in a good UX because the comments will be refetched after saving to show the user the comment they just created. Why this is Secure Concerns

Investigate Web Authentication

Problem Solution Alternative: Seed Phrase with Local Storage Cross-Domain Strategy Implementation Strategy

Navigation

I am creating this document here because I can't discuss new materials on Eric's document.

Improved Product Infrastructure

App Engineering Brainstorm

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. Formal Definitions 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. Modular Protocol There should be a mechanism to extend the Hypermedia protocol for additional applications, extending the Formal Definitions. API Cleanup 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. Formal Definition Codegen 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. Peer Reputation Management 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. Peer-Account Connections 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. Improve the Sync Protocol 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 Snapshots Change-based Entities should support Snapshots, so you don't necessarily have to crawl back the full history to see the latest state. Resource Management 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 Advanced Node Configuration Peer nodes should support varied modes. Many of these could be enabled together: API Documentation Once our API is improved, we should properly version it, document it, and open it up as part of the protocol. Integrated Payment + Service Protocols 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) Private Data Syncing A user wants to have multiple devices, with their private information securely syncing between them. For example drafts and favorites. Direct Messages SHM users should be able to message each-other securely and privately. hmProto v1 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. Revisit Mobile Strategy Make sure we support native phone apps, as first-class citizens alongside the web and desktop app. Rethink the middle-end 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. Move Keys to JS 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. Release JS Client We could release the JS client library which allow our clients to delegate most functionality to the API, while retaining their keys and privacy. Consider Encryption-at-Rest Be careful about what we store in plain-text on the user's machine.

Other Projects in Our Domain

AnyType Kosmik Bluesky + AtProto Veilid Spritely P2P Panda SSB PZP (SSB successor) Farcaster Mirror/Paragraph Urbit

Improving Web Performance with CDN Integration for Seed Hypermedia

Background Problem Technical Clarification Proposed Short-Term Solution: Pros: Limitations: Future Considerations: Next Steps:

Improving Discussion Visibility on Site Home Documents

When a reader arrives at a Site’s Home document, they want to see the most relevant conversations immediately. Today, we only show:

The `Create Document` button is bad align