mawise

I love to see the human-centric vision! This reminds me of Lenovo and Microsoft's "table computer" experiments from ~15 years ago. I remember being really excited at the possibility of my coffee table also being a computer--shared experiences, board games (I think lenovo even sold dice and pawns that connected to it). I had visions of having it also connected to the TV/Projector for controlling media. That was even before I had my first "smartphone". It could have been really cool!

In the animations of the screw cutter, is the threading reversed on the screw that moves the cutting tool? I was staring at the point where the threaded screw meets the carriage in the first animation to see if the carriage was moving very slowly, or just looping in place. It looks like the threads would push the cutting tool in the opposite direction of where it is actually moving.

Very nice work, thank you for sharing!

What's your app? I'd love to try it out!

I get excited every time I learn about another E2EE messaging app where the server can be self-hosted. But as I understand it, the server that triggers push notifications for any android app must be hard-coded into the app's binary. Are there any good architectural workarounds for this? I've read a little bit about VAPID[1] but I don't know if it is actually a viable approach and I don't think I've ever seen it promoted in an E2EE messaging app with a self-hosted server.

[1] (Disclosure: the AI gave me this link) https://unifiedpush.org/news/20250131_push_for_decentralized...

This isn't the hard part of self-hosting, at least not anymore. In the comments here there are lots of examples of similar projects that solve basically the same problem (app selection and deployment). To make self-hosting "easy" we need to solve domain registration, DNS management, and port-forwarding configuration.

This probably requires a project more like OpenWRT that includes an API-driven relationship with a registrar. The lack of a standard (consumer accessible) domain registration API is a huge hole in automating this. If such a project gets some traction, then it could migrate to a physical router that prospective self-hosters could buy. With domain registration, DNS management, and port forwarding all in the router's software, then the remaining hard parts can be sufficiently automated to make self hosting accessible to the average gaming console owner.

Has anyone built a dedicated OPDS client for the Kobo?

I've experimented some with the Kobo ecosystem since I got my Clara BW, I've played with NickleMenu, Plato, and KOReader. KOReader has a built-in OPDS client, but KOReader is a bit heavyweight and it would be really nice to have a dedicated stand-alone client (especially one that supports credentialed OPDS feeds like calibre-web exposes)

I've been using .lan, referenced in rfc6762[1] as a good alternative to the multicast .local

> We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose:

      .intranet.
      .internal.
      .private.
      .corp.
      .home.
      .lan.

[1]: https://datatracker.ietf.org/doc/html/rfc6762

I turned up the following in my searching:

https://cncnet.org/red-alert-2

https://github.com/OpenRA/ra2

Sharing my experience as a tinkerer, sideloader, and recent Kobo owner.

I used a Kindle for ages, always in airplane mode and only sideloading content. Honestly, it was a pretty good setup.[1] But it seemed like it would be harder to setup this way on newer devices, so when mine finally failed, I got a Kobo Clara BW. I was thrilled I could boot it up in "sideloader mode" and not even register it or enable wifi.

I noticed poor typography on my epubs, learned about converting to kepub so I did that (which helped). It was a familiar flow to what I was used to converting to azw3 for the Kindle. My remaining typography gripe with kepubs is that it treats a word+em-dash as a word for inserting space in full justification. Em-dashes generally don't have spaces on either side, this often looks like a space has been inserted only to the right of the em-dash.

I went down the rabbit hole of NickelMenu and other readers including KOReader and Plato, and even tried (and mostly failed) to vibecode my own opds client app. (because KOReader which has one built-in felt overwhelming)

My current sense is the device feels so much more like it is mine. I have much more flexibility to tinker with it. It is not as polished as the Kindle and the Adobe rendering feels stupid, but that's also a sharp edge that only the side-loading community will hit, most of whom use Calibre which can auto convert to kepub for them. Everyone else is buying books from the Kobo store and getting them delivered as kepubs.

So in the end, I'm a big fan of the Kobo devices.

[1]: Except you cannot remove a wifi password if you aren't in range of that wifi signal. I had a rude experience when my two-year-old was fiddling with my Kindle at my in-laws' house and turned on the wifi where there was still a saved credential. An update triggered immediately and I was frustrated for days that everything in the UI changed.

Referenced but not detailed in the article: under android settings -> Apps -> AI Core, you can disable the app and clear the stored data.

Human trial in 2025 looks promising?

https://pubmed.ncbi.nlm.nih.gov/41160460/#:~:text=ResultsAt%...

I consider myself pretty pro-privacy, but there is so much dragnet surveillance and legitimate breaches of the fourth amendment that I have a hard time getting up in arms over a company complying with a valid search warrant that is scoped to three hard drives (and which required law enforcement to have physical possession of the drives to begin with).

This is so much more reasonable than (for example) all the EU chat control efforts that would let law enforcement ctrl+f on any so-called private message in the EU.

The article goes back and forth between bloggers who "are doing well" (ie: making money) and efforts that are non-commercial. It comes across as asking humanity to put more effort into writing and publishing in a non-profitable space while the blogging incentives are profit. I still think the unexplored space for blogging (and the LLM-proof space) is _private_ blogging--for friends and family. But maybe Facebook killed that space off, who knows.

Also worth reading, the IndieWeb's "Social Reader"[1] concept. Built more on websites/blogs as the foundational units.

[1]: https://indieweb.org/social_reader

Um, I'm building this? [1]

The one key element I added was privacy. If your posts are private to your social group then there is no mechanism to try appealing to a broader "viral" audience. Also--if it is decentralized then the company (or person in my case) building it can't change their mind and start selling your data/eyeballs.

I have a LOT of thoughts in this space. Lots of people think they want some sort of healthier social-media alternative, but we're fighting against systems that are so finely tuned engagement monsters that is hard compete to protect your attention and time.

Herman- I'll reach out to you by email!

[1]: https://havenweb.org

I met a guy a while ago who's passion was enabling self-hosting. His vision was to use an old android phone as a server--he ended up building a domain registrar[1] to facilitate OAuth-style flows for configuring DNS and an ngrok-style proxy[2] service that could configure DNS through said flow.

[1]: https://takingnames.io/ [2]: https://boringproxy.io/

Commentary by Cal Newport: https://calnewport.com/an-important-new-study-on-phones-and-...

(open source) Self-hostable, private social media alternative (like Facebook circa 2012). Functionally it is a private blog that speaks RSS with a built-in RSS aggregator. Self-hosting being the only way to actually have privacy in a social-media-type space.

https://github.com/havenweb/haven