Read on Twitter
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
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
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
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!
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.
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...
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
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
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
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
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.
