Revert Semantics

The restore button in the history. Does it do a "git revert", by creating a new change. Or does it do a force-push behavior where it actually replaces the ref and brings latest back to the old change

Restore Documents: What should we do technically?

Synthesis ——— I'm working on a "restore" workflow that let users restore a previous version of a document by clicking a button in the version item inside the versions right panel. The implementation I'm doing right now is very simple: Just create a new version with the content of the restored version. mentioned that there are other technical ways to do this, and this document is to address those options and decide which one we want to implement internally. The UX and UI for it is will be determined soon, but the technical decision I believe should not affect the UI/UX.

Currently the "git revert" workflow is acceptable.

1 second loading time

Loading STT takes over 3 minutes (more, but the user gives up). This site is very difficult because it queries lots of site content.

How are we solving this? Julio is optimizing the server-side of sync reconciliation. Organizes data.

De-prioritize media syncing! Of course!

hm://z6Mkq9emq1yUBq4KSeiSH5yzgNBJSnidPVqFnTpzjCdLxB3R/:profile is leading this issue.

Two possible approaches:

Light Node Syncing

Burdi says this is too complicated for now, because we need to reconcile our local full-node state with the light node state (the snapshot that the server has sent)

Basically this requires trusting the state on the current server, while the full node sync is happening

Fix performance of Full-Node Sync Approach

Julio is researching the performance of our current approach.

Desktop Identity Branch

Burdi is working on flakyness on desktop vault linking: web reports that desktop vault is linked, but desktop is not linked.

Burdi also addressing issue with "Join" button. Old browser state (pre-vault keys) is breaking the experience. 85% sure this is only affecting old users pre-vault. De-prioritized

Discussing Change Metadata

We want to add "message" to a Change blob. Git has very ugly semantics where the commit message is used to annotate a revert commit.

No .attributes field. Only hoisted values.

Static values for now, static types for each attribute in golang- top level values only

Eventually we will support arbitrary attributes with the schema system.

Discussing Metadata Hoisting Semantics

Blocks have attributes in saved in two ways: Block attributes are saved in 2 ways

.attributes object - old content, and new comments signed by the frontend

Hoisted attributes to the top of the block- new convention that the daemon uses

hm://z6MkgisVMELvqnsCo3dYmtVpy8PiqPGMVwfAyBWFn84vebq4/:profile?v=bafy2bzacebcdqgkczlb6f6y4pfhegwdd27tomlrxwxmyai6kyr4mk2i5rxbks&l will write a document about this!

HTML has similar with data- attrs. HTTP has x- headers but arbitrary headers are resepected.

New semantics: top-level attributes are respected first, followed by attributes. fields.

Where to keep documentation about the code

For agents. Where is the source of truth? md files in the code (synced with git workflows). Or do we have seed docs.

hm://z6MkgYR76i3w2Xc2fcvgFJWfYjsop6YwUonDhQx3AdLmQ4BQ/:profile says that code is the best documentation. No low-level docs, only architectural docs. He recommends markdown in git as "source of truth"

Dedicated site which is only reflecting repo markdown. <- best choice for now while we are using git.

Things like projects describe changes to our system - remain in team site.

For architectural stuff and protocol docs - paper of record is md in git.

Gabo wants to read code inside Seed app

Annotations as a layer on top

Annotations sourced from web content - not only HM proto.