Thread by @Conaw

So @phonetoroam is probably the @RoamResearch js extension that has had the biggest impact on my workflow so far.

Uses a simple and elegant "hack" to do things I had not imagined possible

If you've been waiting for our backend API, you'll want to know about this

Quick thread

The problem:

Roam is still running off the local first architecture I developed in 2017 to optimize for rapid iteration and a snappy editing experience

The backend is an event stream of edits, all logic of the graphs is on the frontend

There isn't a server in traditional sense

This is one of the reasons large graphs in Roam can be slow to load initially, but consistently have snappy editing -- we optimized for the writing and collaboration experience at the expense of being a great tool for publishing your ideas (at this stage)

It is also one of the reasons we've been slow to do things that people assume are table stakes -- ship a mobile app, provide link previews, allow cross graph sharing, or more granular permissions -- these, like many interesting 3rd party plugins, need a server with more knowledge

Switching out our backends has been a goal for many months -- but it's sort of like changing the engine on an airplane while you're in flight -- a lot harder to do than on the ground -- and we're not about to take any risks that could cause data loss or substantial downtime

Now, we've got a new backend that we're playing with in development right now, one that allows for way more functionality

But this isn't the sort of thing we're interested in taking risks with, so we're taking our time to roll out

which is why this @phonetoroam trick is so big

Here's how it works

When you sign up with @phonetoroam they generate a phone number you can text - they give you a roam/js script to add to your graph

roam/js scripts are how all roam plugins work today.. nbd

but this script includes an ID that maps to a spot in THEIR servers!

So - when you text the number - the text you send is stored in the PhoneToRoam servers, and then it just, sits there... until you open your graph

When you open your graph, their script pings the server, looks for matching ID, then looks to see if there are any new notes to sync.

The tradeoff: notes you're texting to that number are stored in servers that don't belong to Roam...

They might not have as strong a privacy guarantee in their terms of service (if they have any).. and a hackathon project has far less to lose than us if trust is ever violated...

But that said, idea of using a unique ID added to frontend script to connect a graph to data in a 3rd party server, and to sync via long polling... Feels pretty big

Means anyone following that pattern could build

Email 2 Roam
Web history 2 Roam
Browser Highlights 2 Roam
+ more

Last thing, and can't say this for sure but @kylemathews might know

I think that this idea + all the improvements we've made to the frontend API could MAYBE allow you to use Roam as a CMS for a @GatsbyJS static site that would load crazy fast and be a really great way to publish

And like I told Dan and everyone else who complains about obvious risks of "hacking" your own roam or using scripts from the community

if you are worried about security DO NOT CLICK THE RED BUTTON that says THIS IS NOT SAFE

We give you power, use wisely

https://twitter.com/3266miles/status/1380101412382781440?s=20

Hold up - I should make this caveat, and caveat on all Roam/JS scripts much stronger...

Roam/JS is an EXTREMELY powerful API, it can do anything you can do, up to and including access notes in other graphs you control besides one you load it in.

Be VERY careful who you trust

I’ve been particularly concerned to see such a trend of people having loader scripts in Roam/js block, but putting actual functionality as closed source on a third party site — Yes, it allows for bug fixes, but also allows developers to sneak in changes you might REALLY not want!

We’re working on building Roam Depot so we can review changes and look for code that could be malicious before it goes out — till then, be aware that if any Roam/js dev who uses loading scripts lost control of domain where they host them, very bad day for everyone w that plug-in.