May 2021 Priorities: Self-Hosted RTC, Handbook Structure, and Website

[tangjeff0]

Legend:

• P1: high priority
• P2: medium priority
• P3: low priority

Backend

P1: self-hosted RTC | Status: in progress | Next steps: make @arkRedM's multi-writer approach stable and/or attempt a single-writer approach

• @arkRedM's approach: multi-writer, use rule invariants to enforce implicit rules and fix bad data. Needs to heavily test to ensure no bugs.
• @neotyk and @tangjeff0's approach: centralize events to a single backend writer. Decouple events and stateful tx-data construction

P3: Spec out Homebase/Datahike Collaboration | Status: backlog | Reason: need a stable backend before we can use a Homebase PaaS | Next steps: discuss collaboration via contract work | Waiting on: them

• cc @smothers @rubinovitz
• This would allow users to easily spin up "on-prem" Athens for their team/org
• Open Questions (maybe should create separate discussion here)
  • Server-Sent Events vs WebSockets
  • Datascript vs Datahike vs Datalevin vs Crux vs Fluree (choose provider for both frontend and backend)
  • Cost/contract structure

Community

P1: v1 Website | Status: in progress | Next steps: Shanberg and/or tangjeff0 make device-responsive

• MVP content
• polish design
• link: https://athens-research.webflow.io/
• Related Website #509 , Marketing #1067 by @seekanddefine and Second Brain #1072 by @Limezy

P1: Gitbook Handbook Documentation | Status: in progress | Next steps: @seekanddefine creating 1-3 levels of structure for Handbook

• See #1078
• a table of contents and foundational structure for long-term docs at Handbook.
  • This is what most of our Mid-Month Review covered. See retrospective on mix-up
• Centralize all documentation -> Migrate ClojureFam / School of Athens docs to here and archive ClojureFam

Figure out differentiated strategy for Athens | Status: Done for now

1. focus on research, not "All in-one workspaces" for notetaking, task mgmt, project mgmt, etc.
2. focus on collaboration, first self-hosted then cloud-hosted

Goal could be renamed to "Figure out beachhead market and ideal customer persona, and orient product, marketing, and sales towards them."

Frontend

No P1 priorities

Notes from Mid-Point Sync

• core editing experience - most buggy from frontend POV
• multiplayer/presence UI - more aligned with remote dbs. could use help here to understand code
• db-picker - more aligned with remote dbs
• native toolbar - low priority but just want to close
• db-perf - junius working on it

P2: core editing experience via ContentEditable and DB Performance

• migrate to a ContentEditable library for editing, e.g. ProseMirror
• improve performance for transacting blocks and search by optimizing datascript queries, moving off of posh, and properly deref'ing reagent atoms

P3: general polish

Lots of other areas and issues for general improvements (like accessibility), but don't need to be done in any order.: https://www.craft.do/s/MAGVSD9LgwXSnF

[juniusfree]

properly deref'ing reagent atoms

@tangjeff0 I'm learning reagent. Can I try this? What needs to get done here?

[juniusfree]

indexing is faster on initial load. but posh is faster on re-render (e.g. opening a bullet, changing title)

EDIT: because posh checks first for changes before the updating

[juniusfree]

removed posh from the codebase and updated with datascript equivalent functions. problem is reactivity.

[juniusfree]

@tangjeff0 #1167 let me know if this is what needs to be done. Will update more later.

[tangjeff0]

This looks great @juniusfree. Nice job using entity API. For the parts that need reactivity, we may need to create our own reagent wrapper around datascript.

Also I see you are logging time. There was some prior work here at #784

[juniusfree]

Thanks @tangjeff0. I'll check how that works.

I also copied this from that ticket. (reagent/atom (d/empty-db schema) :meta {:listeners (atom {})}). But I need to test more if this make the components reactive.