To me this sounds like a computer-generated voice for obvious pro-privacy reasons for this kind of project. If it bothers you, then maybe work on better voice synthesis tech! I assume it sounds not-leading-generation because it was locally rendered but I could be wrong.
Why stop at software? Open-source software is a good idea in election systems. The principle could be better generalized as an "open" (copyleft licensed) process for the entire system, regardless of whether the election system is implemented as software or not.
Anyone who talks about election security should be required to spend at least a few moments walking around Defcon in the election machine hacking village. Even absent electronic voting machines we still need to apply that same level of rigor to security across all domains of the election system no matter what format is used.
More fundamentally, the epistemic meaning of a ballot, a vote, or an option on the ballot, how options are even decided for inclusion or their exclusion, which outcome deciding algorithms are used, and how "the result" is interpreted by society or implemented by a political agent is deeply confused. The vote itself has very little resemblance to what actually happens. Such things likely cannot be formally specified anyway. Massive amounts of ambiguity, noise, error rate, and insecurity are to be expected in these kinds of systems. So what then are we even doing with all this? I am not referring to what we say we are achieving, or what we say we are intending to achieve, but rather what kind of actual outcomes be can supported by careful engineering of all these components?
Note that Asterisk magazine is basically the unofficial magazine for the rationalism community and the author is a rationalist blogger who is naturally very pro-LessWrong. This piece is not anti-Yudkowsky or anti-LessWrong.
Hi, your docs say that users don't need state syncing, but when using Stripe you do need state syncing or to ingest the Stripe events. I also don't see any information in the docs about handling e.g. chargebacks or other events and listening for (or otherwise syncing against the history of) those events. I'm a little confused - why would I want to not have that? I could be misunderstanding this project though!
Ah yes, we're still entirely built on Stripe, so all your chargeback management, tax handling, subscriptions and payments are still handled by them! We are not a Stripe replacement.
When our users integrate Autumn, they don't need to handle the state syncing or any Stripe events, as we do all of that for them.
Eg, one of your users, John, subscribes to a Pro tier. We'll listen to that event from Stripe, and grant them access to the right features (eg premium analytics and 100 messages).
From your app, you just query Autumn to ask "does John have access to send messages?", and Autumn says "yes".
When the John's payment fails, we again handle that event from Stripe. Now when your app asks whether John has messages, Autumn says "no, their payment failed".
When you log into Stripe, you can still see everything as normal, and take actions as you normally would!
Edit: now that I'm writing this comment, I realize that we probably should be listening to the chargeback event so we can block access to features if that happens. We'll definitely handle this case, it's just that no one has needed it so far...
Huh, weird. I don't think I have ever wanted to login to Stripe and take manual actions. Usually I hook up Stripe events to actions in my applications, like "The user subscribed, wire them up to the drip lifecycle" or "The user unsubscribed, remove them from a certain marketing list and try to schedule an exit interview" or other hook-ups.
Ah yes. Interestingly most of our users don't set this up in the early stage. But for the ones that do, they need webhooks for this. We have a single webhook that fires whenever a customer's state is updated (eg subscription started, cancelled, downgraded, expired) etc, that the downstream functions you talk about rely on.
That is awesome. A list of power tools on Amazon went from 2.5MB of HTML to 236KB of markup. That is huge! Wow, thank you for sharing.
This is half the equation. Also, lot of the information in the markup can be used to query elements to interact with because it keeps the link locations which can be used to navigate or select elements. On the other hand, by using the stacking context, it is possible query only elements that are visible which removes all elements that can't be interacted with.
> How do you know it's not selected because it's the one with the most paid ads? Or reddit fake reviews? Or llm generated seo articles about it?
These questions apply to any review or recommendation, from anyone, not just LLMs. How did anyone find out about the product at all? Did they do rigorous testing before they made a recommendation? Is there shared understanding between the recommender and recommendee about desired level of quality or what the user intents that need to be satisfied are? Are they even speaking the same language? Is their concept of "red" the same as ours?
At some point, you have to make a decision and buy with imperfect information, and treat it as an experiment. If it's not right for you, then return it for a full refund from Amazon. This is unfortunate. It costs money, time, and adds lots of friction to the whole process.
Maybe advertisers or manufacturers should post quality assurance bonds for their products, in addition to money-back guarantees or easy returns. Upon receiving a lemon or dumb product, you would return the item and activate the arbitration/bond clause and possibly get money out of the posted quality assurance bond.
> These questions apply to any review or recommendation
Sure but even on HN people seem to treat them as some kind of omniscient Gods or oracle of truth. It's like we all lowered our defences and stopped being critical because the new circus monkey does cool tricks.
At the end of the day they're blackboxes built on stolen data by for profit private organizations, all the red flags are here
You can also directly pull in the emulation state and map back to game source code, and then make a script for tool use (not shown here): https://github.com/pret/pokemon-reverse-engineering-tools/bl... Well I see on your page that you already saw the pret advice about memory extraction, hopefully the link is useful anyway.
Well it's definitely possible to have different takeaways from the same book. I can't remember what I took away as a high school student, but when I read it again in my late 30s (I think) it blew my mind a little bit because I had adopted a sort of libertarian view that anything that doesn't directly impede the happiness of someone else should be legal. Coming down to the idea that personal happiness is ultimately what I want (not just for myself; for everybody). Brave New World (which is almost 100 years old at this point) says, "OK, here is a world where everyone can be happy all the time. What do you think?" And as a reader, of course I'm on the side of John Savage. The Soma holiday and ignorance (bliss) is not what I'm after. And of course, without contrast against strife and unhappiness, how can there be happiness at all?
I would use something like inboxchat.ai, sort of. What I want is to get proposed labels based on my usual labeling activity, and then I want to periodically login and review recommended labels for the activity (unlabeled unread pending email) in my inbox, where I would either speed edit some of the suggestions or accept the recommended labels.
While I have hundreds of auto-label filters already setup, there's always constantly more activity to consider. So having label recommendations could save a lot of time. Or proposed new filters based on common obvious labeling activity already occurring in my inbox.
reply