751–760 of 1001 posts
Working on [redacted], a Chrome extension to make YouTube more time-efficient (and way more fun). Its main differentiator: hover any thumbnail (homepage, search, shorts, etc.) for an instant mini-summary, like Wikipedia link previews. Also includes detailed summaries w/ timestamps, chat w/ video, chat w/ entire channels, and comment summaries. Hover & Detailed summaries are free if you plug in your own OpenAI API key…
I'm building Recon Wave ( https://reconwave.com ) - we monitor companies online perimeter and let them know when something's wrong. Recon Wave basically finds and scans all their services - DNS, IPs, Apps, Ports - and notify customers when it breaks some policy (aka. "no ports than 443 should be open") or when some service is straight vulnerable. I'm former security engineer and I hated all that "critical reports" th…
I've been working on a new software product (native Windows) that is for analysis of SQLite databases. It's geared towards non-technical and slightly technical who may not know anything about SQL. The software includes an ER diagram, ability to browse table data, query building, and charting (bar, column, histogram, line, pie, scatter). Trying to get it finished up so that it can be released (hopefully in next few weeks).
https://gitlab.com/harford/xflog
I've also built a tool in Rust for munging ADI (amateur radio contact logging) files:
https://gitlab.com/harford/adifsurgeon
After being laid off, it's given me lots of time to play on the radio :-/
I'm thinking a lot about RSS/Atom, how great email is to read content, and the intersection of these ideas with the W3C WebMonetization spec. I think there's an opportunity to do novel things in this space, and LLMs might help in terms of providing summaries that people actually want. I'm building this for me, but I think it could be useful for other people, too.
Taking a look, it seems quite underwhelming[0] :( Lack of monetization on the web gave us the ad-driven content model that LLMs are now hovering up.
Have there been any other proposals for monetization?
I think it's interesting to think about how much something like that might affect the career of an athlete, especially early in their career or someone who is on the margin of getting into professional sports. Would choosing to play at a university that has a lot of natural handicaps be the difference between making it into pro sports? I wonder.
Anyway, I ended up making a page showing how much baseball teams in MLB have to travel this season: https://calcubest.com/sports/mlb2025 which I think does an OK job of highlighting how much less time athletes playing on central division teams have to travel.
I'm working on a plaintext, decetralized, distributed (multi-device), trustless (multi-user), immutable, schemaless database that's syncable via SyncThing. The trustless part, fundamentally, comes from records being signed by the authors, each device/user keeping track of signatures (ids) seen, and each device periodically publishing all ids it's aware of: that seems to defeat all attacks or accidental corruptions I…
As someone that uses Syncthing for pretty much all the usecases you mentioned that sounds very interesting! Do you mind sharing some details about the process so far?
- It will work as a library that a tool (e.g. family finance tracker) would be based on;
- Every record will be immutable and undeleteable; the whole thing is space inefficient, though I've some mechanisms in mind for pruning away unnecessary records, and it's just plain text, so I'm not worried: should compress well; I wouldn't envision something like this working well on a very large scale though;
- Editing of preexisting records will be implemented as adding a new record that simply references the previous one as its previous version; also, you can implement a ledger by creating a parent-child chain (though the tracking of signatures I mentioned previously might be a simpler approach);
- I like the append-only model because it gives you history of edits for everything, and protects you in case of mistakes (or malice);
- You'll be able to collaborate on records (and the whole db) with other devices/people; every record will be signed by its author/device; conflicting edits (records marking the same record as their parent) will not be deconflicted automatically by the db: the high level app can choose how it wants to do that: throw up an alarm for the user, ignore the older fork, whatever;
- SyncThing-compatibility will be achieved by simply having each device only edit files specific to it; there won't be a single file that is edited by more than a single device/user, thus, SyncThing conflicts can't happen;
- The db will have fairly good guarantees: if it runs its checks and tells you all's good, you can be sure that records were not changed, there is not a new record masquerading as an old record, a record was not secretely deleted, records weren't reordered, another device didn't edit some other device's files, every record's author is its author;
- It was important for me to make the database easily editable and readable via regular text editors, i.e. not only plaintext, but text-editing-centric, but I've not found a way to do that at the lowest level; right now I'm contemplating using some variant of JSON for the records; however, I do envision a text-interface where the database, or a database query/subset, is rendered as a text file, and edits are automatically picked up by a daemon and translated into new records in the actual db, but that would be just another tool using this db, not a feature of the db itself;
- Like for anything synced via SyncThing, the user (or an app using the db) will want to implement some kind of backup (SyncThing is not meant for backups), unless the data is not sensitive to loss.
it's Flickr but for wildlife photography. A good olde fashioned web app. Made it to learn Nextjs as much as anything which was interesting, but got some good lighthouse scores, so hooray