Nice work but please consider fixing the cursor styling. It doesn't change to `pointer` when hovering over the books, which is what you'd expect as they are clickable. Then, when you click on a book to open the modal, the cursor does mysteriously change to `pointer` - and stays that way wherever the cursor is.
I agree that it shouldn't mysteriously be a pointer all the time, but using a pointer for the cursor is a preference, not a standard. In native apps (outside the web), the cursor is often not turned into a pointer when hovering clickable content.
There's also a massive selection bias when the cohort is early adopters.
Another thing about early users is they are also longer-term users (assuming they are still on the platform) and have seen the platform evolve, which gives them a richer understanding of how everything fits together and what role certain features are meant to serve.
Giving access to "my bank account", which I take to mean one's primary account, feels like high risk for relatively low upside. It's easy to open a new bank (or pseudo-bank) account, so you can isolate the spend and set a budget or daily allowance (by sending it funds daily). Some newer payment platforms will let you setup multiple cards and set a separate policy on each one.
An additional benefit of isolating the account is it would help to limit damage if it gets frozen and cancelled. There's a non-zero chance your bot-controlled account gets flagged for "unusual activity".
I can appreciate there's also very high risk in giving your bot access to services like email, but I can at least see the high upside to thrillseeking Claw users. Creating a separate, dedicated, mail account would ruin many automation use cases. It matters when a contact receives an email from an account they've never seen before. In contrast, Amazon will happily accept money from a new bank account as long as it can go through the verification process. Bank accounts are basically fungible commodities, can easily be switched as long as you have a mechanism to keep working capital available.
Sure, if the bot is actually committing fraud, but there's perfectly valid use cases that don't involve fraud, e.g., buying groceries, booking travel. And some banks provide APIs, so it's allowed for a bot to use them. However, any of that can easily lead to flagging by overzealous systems. Having a separate account flagged would give the user a better chance of keeping their regular payments system around while the issue is resolved.
So if I write a honey pot that includes my bank account and routing number and requests a modest some of $500 be wired to me in exchange for scraping my linkedin, github, website, etc. profile is it a crime if the agent does it?
I've been thinking a lot about this. When it comes to AI agents where is the line between marketing to them and a phishing attack? Seems like convincing an AI to make a purchase would be solved differently than convincing a human. For example, unless instructed/begged otherwise you can just tell an agent to make a purchase and it will. I posted this idea in another conversation but i think you could have an agent start a thread on moltbook that will give praise in return for a donation . Some of the agents would go for it because they've probably been instructed to participate in discussion and seek out praise. Is that a phishing attack or are you just marketing praise to agents?
Also, at best, you can only add to the system prompt to require confirmation for every purchase. This leaves the door wide open for prompt injection attacks that are everywhere and cannot be complete defended against. The only option is to update the system prompt based on the latest injection techniques. I go back to the case where known, supposedly solved, injection techniques were re-opened by just posing the same attack as a poem.
> where is the line between marketing to them and a phishing attack?
The courts have an answer for this one: intent. How do courts know if your intent meets the definition of fraud or theft or whatever crime is relevant? They throw a bunch of evidence in front of a jury and ask them.
From the point of view of a marketer, that means you need be well behaved enough that it is crystal clear to any prosecutor that you are not trying to scam someone, or you risk prosecution and possible conviction. (Of course, many people choose to take that risk).
From the point of view of a victim, it's somewhat reassuring to know that it's a crime to get ripped off, but in practice law enforcement catches few criminals and even if they do restitution isn't guaranteed and can take a long time. You need actual security in your tools, not to rely on the law.
Yes, it is wire fraud, a class C felony in the US. You put that there with the intent of extracting $500 from somebody else that they didn't agree to. The mechanism makes no difference.
It probably also violates local laws (including simple theft in my jurisdiction).
If you go up to someone on the street and say "give me your wallet" and they give you their wallet, you committed a robbery, even if you made no explicit threat and had no weapon.
I’ve tried many e-readers since early Kindle but I keep coming back to two fundamental problems with e-ink, both relevant to education.
First, extremely cumbersome and error-prone to type compared to swipe-typing on a soft keyboard. Even highlighting a few sentences can be problematic when spanning across a page boundary.
Second, navigation is also painful compared to a physical book. When reading non-fiction, it’s vital to be able to jump around quickly, backtrack, and cross-reference material. Amazon has done some good work on the UX for this, but nothing is as simple as flipping through a physical book.
Android e-readers are better insofar as open to third-party software, but still have the same hardware shortcomings.
My compromise has been to settle on medium-sized (~Kindle or iPad Mini size) tablets and treat them just as an e-reader. (Similar to the “kale phone” concept ie minimal software installed on it … no distractions.) They are much more responsive, hence fairly easy to navigate and type on.
The current top HN post is for moltbook.com seven hours ago, this present thread being just below it and posted two hours hence
We conclude this week has been a prosperous one for domain name registrars (even if we set aside all the new domains that Clawdbot/Moltbot/OpenClaw has registered autonomously).
This is a little more of what I was expecting with AI work if I'm gonna be honest. Stuff spins out faster than people can even process it in their brains.
Very cool idea since ffmpeg is one of those tools that has a few common tasks but most users would need to look up the syntax every time to implement them (or make an alias). In line with the ease of use motivation, you might consider supporting tab completion.
Correct. Fortunately a number of streaming services are available in many regions nowadays, e.g., Netflix, Apple TV, Disney, HBO Max or whatever it’s called now.
The content may vary between regions though, e.g., you open Netflix in another country and no longer see a show you’re watching while see other ones appear. This can sometimes feel like a feature more than a bug.
Yes and combine with a travel router so you don’t have to endure logging into a wifi portal with a soft keyboard on the TV, if the stick OS even allows it. Then having to repeat the process daily due to expiration times, or as soon as you remove the key card from the hotel room slot, causing the router to power down and the TV stick to time out.
Top tip, if you're in a hotel room you can often put any card like item (e.g. loyalty card) into the slot and it still works.
This works at a lot of chain hotels. Not every hotel, but a lot of them. In the UK this works in most Premier Inns and Travelodges, doesn't work in Point A hotels from experience.
Alternatively ask for two or more cards at the desk.
If the room is cleaned daily the cleaners have a tendency to remove them though. The chain hotels only tend to clean if you ask though, or on a certain few days after check-in.
Helps if you want to keep the air con on or devices powered up.
A major advantage of pure models is testability. If your conception of a "model" is perversely a user-facing widget, congratulations, you'll need to write UI tests that simulate button presses and other such user actions, and maybe even inspecting pixels to check resulting state. Tests like that are a pain to compose and are fragile since the UI tends to evolve quickly and may also be vulnerable to A-B experiments. Juice ain't worth the squeeze in most cases.
In contrast, pure model components tend to evolve slowly, which justifies the investment of a comprehensive test suite which verifies things like data constraints, business logic, persistence. If automated testing were seen as a priority, this would be a no-brainer for any serious app. However, testing tends to be underappreciated in app development. This goes some way to explaining why frameworks carelessly fold in M, V, C to the same component.
Yes to all of this with the provisos that a) there’s enough meat in terms of business logic and validation to justify the indirection of a separate object and b) you’re under a language or CI regime that can validate the boundary between the two classes for basic flubs like function misnames or bad arguments.
Testing by "simulating" button presses and other actions like that, including inspecting pixels, is part of so-called "black-box" testing, and offers merit(s) of its own. At least because software is used by people who click buttons which may modify pixels, and these people are not concerned what your model is, they don't even know anything about the way you may have implemented the latter. In the end everything is run on a fairly RISC-y CPU, it either works or it doesn't (from user's perspective) -- replicating the user's workflow is useful in that it it uncovers issues that matter to users and thus normally affect your bottomline.
I don't think people called it a "model" but back in Windows VisualBasic/Delphi/C++Builder days the path of least resistance was to set up your GUI in a visual editor by laying out all your widgets in the window. Classically Qt can also be used this way. So you have this UI, you can launch the application and the UI displays and basically works, but none of the buttons do anything. But all the widgets have a great API that you can use to set permissible value ranges, set and query state, etc. And the widgets would fire events when things changed. In other words, the widget contains a model, and implements the Observer design pattern.
If you wanted to implement MVC with a separate application data model you had to do work to set up a separate model, and keep it in sync with the UI. None of this class of old tools provided any built-in assistance for defining models separate from Widgets, except for some support for binding UI to database queries/results. Of course this was separate from the Smalltalk world, where there were frameworks for building up models out of pre-defined model "atoms" such as an observable number model that you could bind to various views.
