Activity + Discussion panel fixes documentToText Activity Filtering Feed sorting Video

Week: @2025-10-21: Hypertuesday. During the past week I've been doing work with the feed and trying to find the memory leak. SQLite Memory leak Feed Next Week

Week: . During the past week I've been switching between debugging random issues, and continuing the work on . SQLite Memory Leak Private Documents Next Week

Email Notifications System Documentation Current User Stories Implementation Receive Email Notifications please read this document with user stories for email notifications. Current Limitations Future Development I think we can bring back the accounts table with a flag to determine if the (accountId, email) entry is a subscription or a linked account to email. -- Add back the accounts table with email linking CREATE TABLE accounts ( accountId TEXT NOT NULL, email TEXT NOT NULL, isAccountLinked BOOLEAN NOT NULL DEFAULT FALSE, createdAt DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, notifyMentions BOOLEAN NOT NULL DEFAULT FALSE, notifyReplies BOOLEAN NOT NULL DEFAULT FALSE, notifyDocChanges BOOLEAN NOT NULL DEFAULT FALSE, notifySiteDiscussions BOOLEAN NOT NULL DEFAULT FALSE, PRIMARY KEY (accountId, email) ); The only issue is that email preferences are different for own account and subscriptions. Because of that I would instead propose creating a separate table for linking an account to email. CREATE TABLE email_account_links ( email TEXT NOT NULL, accountId TEXT NOT NULL, createdAt DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, notifyMentions BOOLEAN NOT NULL DEFAULT FALSE, notifyReplies BOOLEAN NOT NULL DEFAULT FALSE, notifyDocChanges BOOLEAN NOT NULL DEFAULT FALSE, notifySiteDiscussions BOOLEAN NOT NULL DEFAULT FALSE, PRIMARY KEY (email, accountId) ); And we could add creation of linking tokens to allow verifying the email address in the welcome email. CREATE TABLE email_account_links ( email TEXT NOT NULL, accountId TEXT NOT NULL, linkingToken TEXT UNIQUE NOT NULL, expiresAt DATETIME NOT NULL, isVerified BOOLEAN NOT NULL DEFAULT FALSE, verifiedAt DATETIME, -- NULL until verified notifyMentions BOOLEAN NOT NULL DEFAULT FALSE, notifyReplies BOOLEAN NOT NULL DEFAULT FALSE, notifyDocChanges BOOLEAN NOT NULL DEFAULT FALSE, notifySiteDiscussions BOOLEAN NOT NULL DEFAULT FALSE, PRIMARY KEY (email, accountId) );      

Some time ago we enabled the ability to create Web Crypto keys in the browser on all Seed sites, for users to be able to sign their comments right on the site they are visiting. Previously they were redirected to hyper.media because this was the only place where their identity key lived, as Web Crypto keys are tied to a single domain and can't be shared securely. Now, this creates fragmentation. Essentially you have a separate account on each web site you are commenting on. Our vision for solving has always been the idea of linking your keys. You account is essentially the set of all the keys you have on you different devices and web sites. So during the past few weeks I've been working on implementing key linking. We already used to have to link desktop keys to hyper.media, but it wasn't suitable as-is for multi-origin world we now live in. So, I'll explain some of the changes I did. It All Begins on the Web Linking Instructions Conclusions

Update: Next week I will continue working on notifications refactor and implementing new subscribe feature for readers without an account.

Problems Solution Rabbit Holes

Subdocuments are part of the content of its parent

Installation Deployment Script Architecture Operational Modes Configuration Management Dependencies Cron Configuration

Full page Search

Import content into seed ecosystem

Problem Solution Scope Rabbit Holes No Gos

Current Setup What Biome Replaces Benefits Risks & Blockers Migration Effort Recommendation Sources

TL;DR What is typescript-go? Our Current Setup Compatibility Blockers What tsgo Does Well (When Ready) What's Still Missing in tsgo Recommended Plan Why Not Now? References

Our document model is a distributed program. A network of computers ran the same program, exchanging messages to maintain a shared state. I believe we can build other Distributed Programs using the same software design primitives. Inbox is a good exercise. Instead of designing the Inbox Program as a centralized program on a server, what if we open the door to make it a Distributed Program? Our principle is to build a decentralized web. How can we keep that promise if a necessary service, such as the inbox service, is centralized? The primitives of Distributed Programs would be:

Two users in a row this weekend have asked for emoticons on the desktop.

What if we introduced a new block type for short videos?