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
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.
Discussions about code syncing to SHM
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime