Fortunately this isn't true. Social media consists of a few big walled gardens, but the web itself is still open. Go forth and create a website!

This was written sarcastically, but I'm optimistic. The more crap that's out there, the more refereshing and noticeable it is when something is good.

My medium term goal is to draw a cursor and move it using a mouse.

I recently got the USB host driver to the point where it could recognise port connects/disconnects. Enumerating USB devices involves some waiting, so I decided to work on concurrency support so that the USB driver wouldn't block the rest of the system. This week I got preemptively scheduled threads working (super fun stuff).

Now I'm trying to make the driver code more self-contained by keeping the driver's message queue on its stack. I'm not sure if it's a good idea. I'll play around with it for another day or two and then get back to USB enumeration.

Wait, so is the browser running a JavaScript build of Qemu? /

Hacker News still has a feed (that's the only reason why I saw this thread). And Reddit gives you a feed for your subscribed subreddits.

That's a weird way to put it.

The commit activity looks unusual because it's a completed project whose files were individually committed in alphabetical order. There's no development history.

What have been the most helpful reference materials so far?

What's the most memorable challenge you overcame?

What's the coolest or most surprising thing you learned?

Any links?

> Maybe this is also why Smalltalk fiends are such fans.

I started getting interested in Smalltalk after I tried writing a MacOS program by calling the Objective-C runtime from Rust and had a surprisingly good time. A Smalltalk-style OO language feels like a better base layer for apps than C.

(I'm not the author) The easiest way to charge for this kind of software is to make it SaaS, and I think that's pretty gross, especially for a CLI tool.

> I'm skeptical and I may just release it all as OSS

It doesn't have to be one or the other: you could sell the software under libre[1] terms, for example.

[1]: https://en.wikipedia.org/wiki/Free_software

I created a little GTK program to help: https://github.com/LightAndLight/gen-alias

A possible piece of the puzzle: I originally read the article on mobile, no issues. Then I opened it on my desktop, and found the design quite jarring. The margins are much too large for my taste, forcing the text into a single narrow column, and the header animations were distracting and disorienting (fortunately the page works perfectly with JavaScript disabled). Perhaps this triggered people?

I run Syncthing to keep my KeepassXC in sync across devices. At the same time I have `syncthing-merge`[1] running to handle any conflicts due to concurrent database edits. It calls `keepassxc-cli merge` to merge conflicting databases, which requires my database password. `syncthing-merge` runs as a system service under its own user, so I wasn't able to use a graphical dialog program like GNOME's `zenity` to ask for the password. My solution is to run a user service that can create graphical dialogs in response to requests from system daemons, while enforcing minimal access to the data that the user enters.

With the required NixOS config[2] in place, a system service calls `asker KEY` to issue a request. If that service is a member of the `asker-keys-{KEY}` group, then the request proceeds, is handled by a user service (`asker-prompt`), and then printed to stdout (i.e. to be piped into another program). I took care to ensure that only authorised services could read the user's input.

I looked into using existing keyring programs via the D-Bus Secret Service API, but I couldn't figure out how to control access to individual secrets. I know exactly which services should be allowed to access particular secrets, and I want to enforce that. In particular, I don't want my logged-in user to have universal access to these secrets, because then any program I run can read them (see also: recent discussion of this issue[3]). I also found that these keyring programs aren't suited for ephemeral data; they store secrets for a while.

It might be possible to achieve this using pure D-Bus with access control policies. I haven't looked into this because after I decided that the Secret Service API was insufficient, I figured that rolling my own protocol would be easier than learning D-Bus.

Questions for you:

* Which wheels could I have avoided reinventing?

* Is there anything I could simplify?

* Have I failed at my security goals due to mistakes or oversights?

[1]: https://github.com/LightAndLight/syncthing-merge [2]: https://github.com/LightAndLight/asker?tab=readme-ov-file#us... [3]: https://news.ycombinator.com/item?id=46278857

Comments URL: https://news.ycombinator.com/item?id=46439560

Points: 2

# Comments: 0

Next up I'm moving my TODOs off Todoist to something local-first, and plugging that into my Syncthing setup.

> If you have a feed reader system there is no need to subscribe [via YouTube] in the first place. You’ve obviated that system.

This approach works, and it's a great way to subscribe to public channels without a YouTube account. The main reason I'm not doing it is that I want to subscribe via YouTube.

> It would be great if it was more discoverable

Oh, hopefully there's a browser extension that detects feeds on a page and lights up and provides a menu. Shame that the YouTube mobile app isn't similarly extensible.

It's not a "Show HN" because there's no way for others to try it (yet).

Some things I'm curious about:

* Is anyone else here doing something similar?

* Would anyone like to use this service?

* Are there other YouTube-meets-news-feed features that you'd love to see?

Comments URL: https://news.ycombinator.com/item?id=44412109

Points: 17

# Comments: 14

My main concern is that it will be hard for you to find people who could give you excellent feedback on this, because they probably have epistemic shields up around this topic due to all the surrounding crankery. I don't know how to solve this, but I wish you luck.