silvianetobessa
commented
2 years ago @dvargas92495 These are raw comments I wrote down as I was reading, take them with a pinch of salt. I share them in the spirit of "providing feedback early and often".
Technical Sponsor:
- open question to discuss with Karola: can David List us TS? Should we link Joel’s and Akamatsu’s grants under the additional info? to contextualise and strengthen the proposal, and emphasise our support?
Project Description:
- add some links to the web2 tools?
- Use case: who’s “your”? Suggestion: Replace with “other user that uses Obsidian”, and emphasise you are mentioning those specific tools as examples only
- >“develop a series of plugins, one for each tool for thought. How many are there? Suggestion: add listed above. Note that on the Deliverables section you leave Notion out of the MVP. Are there plans for Notion later on?
Value:
- In the Description, you mention the creation of a protocol and end up mentioning plugins to create the network. In the Value section, you mention the network. I would advise you to value consistency. Emphasis on the protocol you are building on top of the IPFS network to facilitate communication between TFTs?
Benefits:
- We want to keep this succinct, but assume people reading the proposal do not understand the importance of a shared lab book. Can we make it more general and then give that example? Or alternatively, provide a more “tech saviour” example too?
- I personally like to avoid absolutes, and deeming sth obsolete is probably not sensible. I might want to share this with a non-user of TFT, how would that work without export?
“This would also make most import/export features obsolete”
Development roadmap:
- General comment: for 4 months of development you provide 12 points. Can’t you provide a more limited set of milestones on cluster these details under them? I’m afraid the first reader’s impression is “4 months for such an extensive list? What are the main milestones?"
Team: Joel Chan: should we emphasise he’s not receiving funds at this stage?
- Note that on the Development Roadmap you mention “the same two team members specified in the Team section.” And then you have 3 people under the team section.
- They ask for Linkedin, you provide twitter. Is there a reason for this?
dvargas92495
KarolaKirsanow
Open Grant Proposal:
SamePageName of Project: SamePage Proposal Category:
app-devProposer: @dvargas92495 Technical Sponsor: @KarolaKirsanow and @miyazono Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT, APACHE2, or GPL licenses?: YesProject Description
Tools for thought (TFTs) are applications that are meant to augment human intelligence by providing quick capture of ideas via notes and free association of these ideas via links and references. The space is currently littered with plenty of different web2 options, from Roam to Obsidian, Notion to Logseq. Each of the companies behind these products believes that their specific data model and bundle of user interfaces will be the solution to solving personal knowledge management, and some believe they could grow into the solution that solves collective knowledge management.
However, all users are different and have highly specific needs. This has played out by Notion and Roam starting as the primary two tools of choice, and slowly losing power users to the newer entrants in the space. As users continue to migrate between tools and settle into their preferred UI and servers of choice, collaborating has gotten increasingly difficult. In order for teams of researchers or independent contractors to collaborate, they either need to a) compromise into using one tool, copy/pasting data back and forth from their personal tool or b) import/export data from their personal tool to the personal tools of their colleagues.
Because of this, tools for thought on their own will not be a sufficient answer for collaborative thought. What we need instead is a protocol for thought: a set of decentralized computing resources and adapters from each of these tools. A network that allows users to continue sketching ideas in their personal tool for thought and that tool interfacing with the tools of their colleagues directly.
An example use case: I want to be able to open a page in Roam and have it connect directly with a page in another user's Obsidian vault. We can write changes to the same document asynchronously and they will be resynchronized once connected to the internet.
To achieve this, we plan to develop SamePage, a network composed of a series of stateless lambda functions that will use IPFS as the file storage backend. To help inform the design of the protocol for communicating with this network, we will implement a series of plugins for a set of the previously mentioned tools for thought. In our MVP, we plan to build plugins to connect:
In the future, we want to extend the network to also connect:
These TFTs have proven to be very successful authoring tools for researchers to explore questions and tasks. But no tool has cracked collaboration and because of this few research labs have been able to scale their workflows using any one of them. However, a protocol that allows each researcher to stay within their own tool but could effectively interface between them would allow communication to scale from where they are most comfortable working.
Value
Successfully building out this network would allow teams of people to collaborate with each other without having to all migrate to a single platform. A research lab could have one member in Roam, one in Obsidian, and one in LogSeq, and still be able to share one lab notebook of findings without any of them compromising on their tool of choice. This would provide users of these tools an alternative to the current export=>import=>reformat workflow with the ability to interface with each other directly. Since the proliferation of new tools for thought in 2019, the unserved need to connect work across different software platforms grows.
Through Joel and Brendan's prior research, they've seen this problem repeatedly — it's hard to bring others up to speed, especially when team members use different tools. Even then, when teams don't share the same vocabulary, struggles occur to introduce new team members to a project. David has already made strides to solve this later problem, introducing a multiplayer connection within Roam that allows for different users to share pages — and their surrounding context — to enable teams to collaborate with reduced friction.
The primary user groups we are targeting are those collaborating around either a problem or set of tasks. The former often involves research groups with labs composed of members synthesizing their research on their own tools and currently struggling to find a way to combine their findings and build off of each other. The latter involves freelancers and agencies who are looking to reduce friction around onboarding new clients by allowing each party to stay in their company’s tool of choice. The risks of not getting this right would include data loss while reconciling changes between clients and accidentally leaking private data publicly. Other risks include loss of engineering resources devoted to an idea that doesn't gain momentum or is an improvement from the status quo of users collaborating on a single platform.
To mitigate these risks, we aim to first tackle handling of public data. This will allow us to store and manage every version of a shared page on IPFS without fear of leaking private data. We then plan to iterate with end-to-end tests and user feedback to ensure we are not incurring data loss over time. In the next stage of our grant, we are looking to reach out to about 20 teams of users and onboard them to the network. Given our team’s reputation and experience (see Team section below) in the TFT industry, we are confident that we will onboard the right teams to give us ongoing feedback on whether the network is improving current workflows.
There are also some technical challenges to solve that pose risks for executing on this project, and we plan to address these through the development of our MVP. Versions of the data will fork when one or more clients are offline — how should those changes and potential merge conflicts reconcile? It will never be the case that each TFT will support the exact same set of features as all other TFTs — how should features from one TFT show up in one where the feature is unsupported? Ideally the network with respect to the user data itself could be fully stateless — how can we guarantee correctness without a shared intermediate state? Or how will we know that whichever intermediate format is chosen will be flexible enough for all foreseeable products in the TFT industry?
Answers to these questions are partly technical and partly UX-related. David’s work building Roam Multiplayer lays a great foundation to solve these challenges, and the internal team has been testing and iterating on this design already.
Further, there is a growing body of research around CRDTs (conflict-free resolution data types) and this network will aim to use them to handle risks around merge conflicts. Our connections to the Ink & Switch team, who has published research and functioning applications using CRDTs, will provide us with a community to provide hands-on feedback to our approach. To handle non-feature parity across TFT clients, we will build a flexible data format that allows for generic attributes to be defined. This will push the work for adapting into each plugin, and do so in a many-to-one relation instead of many-to-many translations. AtJson is emerging as a promising data model in this regard, but more exploration is still to be done. With all the code being open source, this will allow for faster future portability and development of adapters in foreseeable TFTs.
Throughout the MVP, we will address these risks via in-house testing, planned technical experimentation, and our feedback from valuable community sources. By the close of our MVP, we expect to have validated our initial approach with key users and communities.
Deliverables
This first stage will shoot for an MVP that will allow syncing changes across Roam, Obsidian, and LogSeq. Deliverables include a plugin published to each of the three apps' stores, as well as deploying lambda functions live to accept synchronous changes between them. There will also be a live WebSocket Gateway to notify online clients of changes by their peers on a shared page.
All plugin code published to these stores are required to be open source. And while we will start the network with computing resources we manage, all code that run on those resources will be open source. This means that teams will be able to deploy a self hosted version of SamePage on their own servers to handle syncing between their TFTs, if we build it with this composability in mind.
Development Roadmap
All milestones listed below will be worked on by the first two team members specified in the Team section. The timelines on each milestone assumes a July 1st, 2022 start date. In general, milestone estimates were calculated by estimating what we needed for four months of development, and reverse engineered from there:
Total Budget Breakdown
$48K - Used to pay two core contributors $6K / month for four months of development.
Maintenance and Upgrade Plans
This grant application serves as stage 1 of a four stage plan to build out this project into a sustainable business model, who's funds will be used to adapt the infrastructure and software over time. See the Launch Plan in this doc for details on the later stages of the project.
Team
Our team is more active on Twitter, so we listed those links first.
Team Members
David Vargas
Brendan Langen
Joel Chan
Team Website
https://samepage.network
Relevant Experience
Team code repositories
Additional Information
We learned about the Open Grants Program through Karola Kirsanow. Her team at Protocol Labs have been funding the development of the Discourse Graph RoamJS extension David and Joel have been working on. We believe synthesizing and collaborating on discourse graphs to be the first major application for research teams to use SamePage. This project goes a step further to accelerate the creation of research public goods, particularly those suited for decentralized collaboration and science.
The best email addresses to reach us at are: