url2epub VS share-file-systems

Somewhat similarly, I wrote a web app to generate epub (instead of pdf) out of urls and send to eink reader(s) directly (via a telegram bot) so I can read them. Currently it supports sending epub by email (for kindle) or uploading epub to dropbox (for kobo, etc.). It originally also supports reMarkable cloud but we can no longer make reMarkable cloud actually work. There's also a REST api to generate epub to be downloaded directly: https://github.com/fishy/url2epub/blob/main/REST.md

For e-ink readers epubs are generally better than PDFs for urls anyways, as epubs are basically packed htmls, and also the flow text works better on smaller screens.

I wrote a service (Google Cloud Run as the backend, with Telegram bot as the frontend) to generate readable ePub from URLs and send directly to e-ink readers. It was originally wrote for reMarkable 2 (using reMarkable cloud), I recently added support for Kindle (by using the send-to-kindle emails). The code is at https://github.com/fishy/url2epub and I blogged about the recently added kindle support at https://b.yuxuan.org/url2epub-kindle.

I'm open to suggestions on what other e-ink platforms to add, as long as they have a reasonable cloud API. I'm also looking for a good e-ink platform to move to personally, as it becomes apparent that reMarkable really doesn't want third parties to use their proprietary cloud "API".

2. It's a relatively open system (compared to other e-ink readers), so it's pretty fun in terms of hackability.

I did get the forever free subscription which helps, but I also totally understand why they would want to charge for that, and I think the new $3/month is a pretty reasonable price for it.

Regarding instapaper use case and also hackability, shameless plug: I wrote https://github.com/fishy/url2epub for my own use case, so instead of relying on a third party service and manually sync stuff to reMarkable 2, I just send the link to the telegram bot (I picked telegram bot so that I can easily send links from my phone, not only desktops), and the epub will be auto synced to my reMarkable cloud account (they did made some changes to the cloud api causing I have to manually open their official mobile or desktop app to sync once before the reMarkable 2 itself would accept the new epub I uploaded through url2epub, haven't figured out how to avoid that yet, but it's still mostly automated).

For reMarkable, I also wrote a Telegram bot to convert http url into ePub and send to reMarkable directly: https://github.com/fishy/url2epub

(if you don't like telegram or don't use reMarkable, it also comes with a public rest API to generate epub out of urls)

Shameless plug and this is only loosely related: Over the last holiday season I wrote a backend (written in Go and running on App Engine) to convert http url into epub. The frontend is a telegram bot that sends the epub to your reMarkable account directly, but it also has rest api to download the epub file: https://github.com/fishy/url2epub/blob/main/REST.md

With the purchase of reMarkable 2, I have this need to easily send web articles to my reMarkable 2 from my phone, while officially they only provided a Chrome extension, which can only be used on desktops.

As a result I wrote some go code (https://github.com/fishy/url2epub) for the past 2 days, to generate ePub from URL. I also implemented reMarkable API to send them to reMarkable tablets directly.

The current UI for it is implemented as a Telegram bot (https://t.me/url2rM_bot?start=1), running on AppEngine (code: https://github.com/fishy/url2epub/tree/main/appengine). I initially considered making an Android app for the UI, but decided that Telegram bot is less work for me, and works good enough for this use case (sorry for people who don't use Telegram, but this also means that people on iOS, desktop, etc. will be able to use it).

For the future, I might do:

- Expand the URLs supported (currently it only supports URLs with an AMP version provided, and the AMP version does have article tag inside)

Some things I learned about trusted localhost HTTPS:

* Windows is the easiest... by far. There is only one trust store and its extremely easy to access at different levels of trust. Firefox has its own trust store so you can either add your certs to both the Windows store AND the Firefox trust store or flip a config in Firefox to tell it to use the Windows trust store like everyone else.

* Linux is a challenge because you have to add your certificates to the OS trust store and then each browser has their own trust stores.

* MacOS is pretty close to impossible, at least fully automated. If the cert is not registered with a third party of the OS's choosing the cert will not be trusted in the browser. The way around this is to manually add your localhost cert chain to the MacOS keychain.

If anybody wants an example here is something I wrote a ways back in JS (but please be warned its specific to my application:

* Build the certificate chain - https://github.com/prettydiff/share-file-systems/blob/master...

* Install the cert by OS type - https://github.com/prettydiff/share-file-systems/blob/master...

That second sample also installs pcap so that I can serve on localhost over ports 80/443.

Some developers believe everything is always a framework or any attempt to avoid frameworks creates a new framework. I cannot help these people. Any non-religion is a cult type nonsense of affirming the consequent fallacy.

Otherwise a valid example is this one file that creates a complete OS-like GUI in the browser awaiting content typically populated from WebSocket messaging: https://github.com/prettydiff/share-file-systems/blob/master...

I wrote a similar concept around private internet access to your file system. It’s at https://github.com/prettydiff/share-file-systems

The window and state management can be demoed on my personal site at https://prettydiff.com

File sharing and soon remote execution over the internet cross OS. Private and no servers.

https://github.com/prettydiff/share-file-systems

Done: https://github.com/prettydiff/share-file-systems/blob/master...

You would need a warrant to extract the messages/identity directly from a person's computer as there is nothing otherwise to obtain.

Perhaps this is true in the context of the web. But I got tired of watching the web as a platform continuously repeat the same mistakes so I started working on something different. In the last day or two I was finally able to functionally prove my competing idea in a way that forcefully imposes privacy with complete Zero Trust conformance.

https://github.com/prettydiff/share-file-systems/blob/master...

I am performing a similar file system tree navigation asynchronously in Node.js which is just a shallow API over the C Linux FS APIs.

I can see you are using opendir and closedir functions? What is the benefit from using the opendir function[1] when readdir[2] can be called on a location directly? Is the benefit that opendir returns a file descriptor for use in opening a stream to gather directory object descriptors?

[1] https://man7.org/linux/man-pages/man3/opendir.3.html

[2] https://man7.org/linux/man-pages/man3/readdir.3.html

Your project is probably more mature but if you want an alternate approach to examine here is I have been doing it: https://github.com/prettydiff/share-file-systems/blob/master...

I considering changing my use of readdir to use the withFileTypes option so that it returns a list of directory entries (objects of artifact name and type) instead of a list of conditions to discern types like I am doing on lines 382-432.

Solved.

Solved for both Windows and Linux (Debian, Arch, Fedora). I might have unlikely solved this of OSX as well, but I am not buying Apply hardware just to test it.

What my solution does is check for certificates created by the project during a build step. If the certificates don't exist it creates them, installs them in the OS, and also install them in the browser. Installation in the browsers is required in Linux and only for FireFox in Windows. These are cert chains containing a self-signed root, intermediary CA, and a local domain cert.

I have these certs configured to work with my own domains so that I can connect to a subdomain addressed to a loopback IP and the cert recognizes that domain, but the domain "localhost" works as well. Sometimes its nice to access a real domain to avoid any restrictions imposed upon accessing address "localhost". You just have to change the domains at the bottom of your OpenSSL option files.

Here is how I solved it with vanilla TypeScript in Node.js (also requires locally installed OpenSSL:

* OpenSSL option file 1 - https://github.com/prettydiff/share-file-systems/blob/master...

* OpenSSL option file 2 - https://github.com/prettydiff/share-file-systems/blob/master...

* Certificate library - https://github.com/prettydiff/share-file-systems/blob/master...

* Certificate interface from build tool - https://github.com/prettydiff/share-file-systems/blob/master...

* Certificate installation - https://github.com/prettydiff/share-file-systems/blob/master...

If you have any questions just open a Github issue on the project.

Email: [email protected]

15 years experience with JavaScript, 6 years experience with TypeScript. I am currently writing a Node based OS in TypeScript to solve for decentralization (not Web3): https://github.com/prettydiff/share-file-systems

I understand performance aggressively enough far beyond the comfort of most developers: https://github.com/prettydiff/wisdom/blob/master/performance...

I started a JS based file sharing application a few years back. It started as a thought experiment of just exposing the file system to the browser in a familiar OS kind of user interface. As new features are added over time it has become more like a high level OS.

https://github.com/prettydiff/share-file-systems

Some architectural decisions I made:

* Micro-service based

* I am now using WebSockets for all services and communication. That has proven in the application to be 7x faster than HTTP.

* I have a universal format wrapping all service messaging, kind of like sending a letter in an envelope. This allows me to using a single service end point for all services and a single means of service monitoring.

* I did not like the existing test automation solutions based upon CDP, because they are too slow and fragile. Also, they do not provide support for a peer-to-peer experience. So I wrote my own test automation solution for testing in the browser and its much faster and predictable.

* I am using an identity based authentication mechanism to restrict access to known users/devices.

* I just write to the file system instead of using a database for data storage. This allows for much faster application start up times and lowers complexity. The performance difference is insignificant after accounting for that in most cases opening a file is more costly than arbitrarily writing to the file system.

* I figured out how to install certificates using automation in both Windows and Linux which allows me to run the application using encrypted transmission protocols (https/wss) on localhost.