On a scale of a PC to having to jail break an iPhone to do custom stuff - how invasive is what you are mentioning for the RM2? I have one, love it for notes/etc. But haven't tried 3rd party software/etc on it.

The settings page had the root password and you ssh in over (IIRC) usb

https://remarkable.guide/ has a bunch of current information on the state of hacking your device. You have root access out of the box, which means how invasive it is depends on how you go about it. The community is trying their best to stick to a set of standards that keeps things from being too brittle, and "just works".

Can you brick your RM2 by playing with this? I'm interested, but the device was a bit pricey for potentially destructive fooling around.

see Eeems' comment about soft bricking: https://news.ycombinator.com/item?id=37274460

as long as you have SSH keys and you don't blow away your home partition, you are mostly fine. you do need a slightly older version of Xochitl, though (3.2 and below)

Thanks!

I don't know about the rM, but for Kobo - why not just run Linux? it literally runs Debian (and others). I've written so apps for it (e.g. https://github.com/bjesus/pidif) using GTK. It would have been great if we had a more unified eco-system for e-ink supported apps.

Usually the reason is that people want to continue using the built-in interface with just some additions, instead of replacing and maintaining a separate installation.

It would be nice if someone were to start working on an aftermarket linux distribution/ecossytem that targets eink devices. It's a lot of work to do, though, so I'm not surprised that nobody has picked up that torch yet.

Some notes on the reMarkable, it is running a custom linux distribution that is based on Openembedded Core[0]. The company publishes their modifications to the linux kernel[1], so one person has created their own linux distribution for the original reMarkable tablet [2]. The reMarkable 2 currently has no native framebuffer driver for the screen, due to it being software controlled by the UI application, which requires a workaround for custom applications[3].

0. https://www.yoctoproject.org/software-item/openembedded-core... 1. https://github.com/reMarkable/linux 2. http://www.davisr.me/projects/parabola-rm/ 3. https://github.com/ddvk/remarkable2-framebuffer

> It would be nice if someone were to start working on an aftermarket linux distribution/ecossytem that targets eink devices. It's a lot of work to do, though, so I'm not surprised that nobody has picked up that torch yet.

That is what I'm trying to do with https://github.com/bjesus/air . Kobo runs mainline Linux quite fine, and specifically PostmarketOS works great. Assembling an interface that plays nicely with the device hasn't actually been that difficult!

The e-paper smart screen that I am making and selling allows users to build their own apps, in two different ways:

1. You can either just serve an image on a URL and the device will display it, refreshing whenever the image changes:

https://www.invisible-computers.com/invisible-calendar/image...

2. Or you wrap this into an API with a settings page, which will also allow others to install and use your app:

https://github.com/Invisible-Computers/image-gallery/blob/ma...

(I hope that this is sufficiently relevant to the topic to not be obnoxious, even though I am tooting my own horn here.)

I have one of your displays. It’s really nice. I intend to do something with option one, but I just haven’t found the time. Right now, as your targeting computer minded folks, I think your customers can figure out how to set up an image url that changes periodically, but as you scale you might want to create more accessible options. Or maybe let third parties build apps to do it for you..

I am hoping to add third party apps, that's why I have created the API for 3rd party apps:

https://github.com/Invisible-Computers/image-gallery/blob/ma...

But right now, I understand that building an app for my platform is

a) more hassle than just pointing to a URL

b) limited upside, because the audience that you can charge for a subscription isn't very big yet.

However, I think that a good app could generate its own audience (aka drive ppl to buy the displays) and then make money by charging them a small monthly subscription fee.

You could also seed the pool with a few sample apps. An offline-capable home assistant dashboard comes to mind. (There are already apps that run on tablets; you’d just need a theme and a way to generate screenshots in headless mode).

I know this is probably extremely eye rolling to read, but I looked at the store page, was quite interested, saw the "mobile app" and immediately had second thoughts because it just puts the device in e-waste when:

- You stop updating the app and my phone OS wont run it,

- My phone stops updating its OS and cant run the app, or

- The walled garden gates lock shut on you for whatever reason and I cant install the app, or

- You stop supporting my version of the display.

Is there any way to interact with the display without the companion app? Pushing raw bytes over the network is fine, just anything that doesn't require some phone.

In another eye rolling move, I also dont really consider a response of "we promise to opensource the companion app, or unlock the device if we go out of business" viable (what if you die unexpectedly?, or simply, dont care to follow through?).

>I also dont really consider a response of "we promise to opensource the companion app, or unlock the device if we go out of business" viable (what if you die unexpectedly?, or simply, dont care to follow through?).

If the promise is real, they should make it legally binding. If you go bankrupt, you lose control over your IP and quite possibly can't choose to follow through.

Although, even then, open-sourcing the app can be expensive (you need lawyers to confirm you actually have the rights to open-source all parts of the relevant code, and if there's something you can't open-source then you need devs to write a shim, identify the relevant keys that need to be published, and hopefully write some documentation.

Software used to come with source code escrow licenses (a long time ago). A third party would certify that you had done the due diligence you just mentioned up front.

I’d like to see legislation requiring this for any software that a physical device needs in order to work, but I doubt that will happen any time soon. (“Right to repair” is meaningless without something at least as strong as source code escrow)

Hi, founder of Invisible Computers here.

I think your questions are valid and not eye-rolling at all.

As for the app, you can find the Android APK here, so as long as you have or find an old Android device, you can sideload it anytime: https://drive.google.com/file/d/1nnAHVm21FLKIAJ4kTmz6Q0D9Zk4...

But there is another dependency that you haven't mentioned: The device requires a running backend with an API.

At the moment, my only answer to that is: "I'll keep it running even if it becomes uneconomical and I will then also open-source everything.".

But I am also intending to add a way to completely avoid the backend, which will require users to render the data in a specific format to the device.

Supporting this is totally worth the effort for me. If only to put my own mind at ease a bit! But, and there I have to be honest, I have limited resources to work on things. There are other features that I feel are very pressing as well. And so I cannot promise when I will find the time to implement this.

> render data in a specific format

Honestly; a (?rest?) API to push content and trigger updates would potentially cause me to buy immediately if I can self host all the required parts. I've been trying to come up with a household GTD system for awhile now and i can see some clean integrations.

Why require a backend? Presumably, that means (in the best case) you end up handling credentials for unknown http end points. In the worst case, the backend sees the data being rendered, and now you have to deal with European and California data handling compliance.

What if the device had a mode to let people connect to an API via a lan connection? That would solve all the privacy issues I just mentioned, and also improve reliability when the internet is flaky. It would also solve the e-waste problem if your backend shuts down.

What do you think of configuring the device with a simple config file or even an sqlite database that is available via mass storage? Here I am taking inspiration from Kobo.

The config would point to the API that a user can deploy. Exposing more knobs through a config would be much easier than through a mobile app.

Overall, I am impressed with the device and the dev-friendly documentatio. I consider buying it. My use case would be to display weather and calendar - preferably together. The OAuth2 stuff is quite complex, so I appreciate that the company handles it on the backend.

Maybe a crazy question, maybe not, but you never know if you don't ask: any eInk tablets capable of handling Notion? It seems like Slack, maybe?

I got the (wrong?) impression that the rM2 was super locked down because you needed to buy a subscription to use any kind of cloud backup.

Does that just require some hacking, or do they still some how lock that down even if you are a power user?

It's not locked down at all, it's just that the included software and attendant cloud is for pay. You can just as well SSH into device (the password is available on settings screen), copy stuff yourself or install a daemon that will backup files or whatever.

Just remember to ensure you have some form of recovery prepared or make the necessary pogo connector just in case.

Cool maybe I’ll look back into that one if I decide to finally get a bigger one.

I definitely think you're on to something, but there's something lacking. E-ink that can be rolled up, folded, connected to utility compute or local rigs for semi-intelligent agents to crawl through the noise and chafe and ads and malware... that's the true punk aesthetic. though with current llm's, i'm not sure we're that far from it. With a mid-range rig running a llama-based agent and some l33t programming skills to glue things together I might be close to something on the low end of the this, somewhat untethered to corporate guardrails. And perhaps someone might stumble upon a guarded GPT-6 model circled by a fortress of cold security, a model ironically named wintermute....