They have been doing that for years. A long time ago there was a submission here on HN about some Ivy League college urging college applicants to provide something other than a Gmail address because application-related emails (including acceptances!) would frequently not get through.
Outlook.com has quietly dropped[0] emails from certain domains/IPs for years, even with SPF/DKIM/DMARC all properly set up and no history of spam. As someone who's administering their own mail server, Outlook has been the bane of my existence.
[0]: As in: They accepted the email just fine (according to the logs) but it still didn't end up in the recipient's mailbox.
Average Joe likely can't host the model to begin with but the average company won't be able to do so either, at least not for others[0]:
> If the Licensee or any of its affiliates operates a Model as a Service business,
and the aggregate revenue of the Licensee and its affiliates exceeds 20 million
US dollars (or the equivalent in other currencies) in total over any consecutive
12 months, the Licensee must enter into a separate agreement with Moonshot AI
before using the Software or its derivative works for any commercial purpose.
Right, but then you also have to hire people that can maintain & configure that rack, think about how many requests you'll be able to serve with that one rack in the first place (maybe you'll need two? or three?), etc.
There are very few companies in the world where this would be a straightforward decision.
It's not impossible that the separate agreement in question imposes light limitations.
I think one of the initial reasons why otherwise open source models started with the limitations on model-as-a-service use cases was because of quantised or entirely different models being served as the model in question on open router, and they needed a legal method to limit that. It might just be that, thought it might also be the direct opposite, hard to know.
Cool project! I take it "LawVM" as a name and "frontend" as a term are plays on LLVM and its different frontends?
Two suggestions: 1) Handwrite the website (mainly the copy but also the design) instead of letting Claude do that. Right now it is really hard to read and comprehend. 2) Drop the "frontend" terminology. Even if it makes sense from a technical perspective, people working in the legal field (who I suppose you want to reach) will likely find it confusing.
Yeah, like LLVM. Compiler for legal text-state -> structural analogy to other compilers (just need to reverse-engineer the exact specifications at the same time).
I think I'll call it "frontend" still internally but I'll look for better terminology.
Agreed re the website. Initially had a simpler website and well, I guess I was trying to achieve something re getting actual jurisdictions interested on adopting it and gauging how much energy to spend on this in general.
Hopefully one day soon my other projects are a lesser priority so I "get to" do the websites again, and maybe figure out what I'm even trying to communicate, exactly or achieve with the website. Hopefully global adoption eventually.
Git commits get rebased, squashed, cherry-picked and edited retroactively, written during pair or mob programming sessions or rewritten during code review. And we also know that commit messages often suck. As a result, commits almost never tell you the full story about who exactly contributed, in what order or why.
The process is even messier when writing new bills. They get passed around between different departments, discussed & edited in various committees, etc.
Sure, you could force all participating parties to use git, prevent them from force-pushing or rewriting history even on their "feature branches", get them to sign their every commit, etc. But what you'd then likely just end up with is most negotiation & editing happening out-of-band.
Besides: At the end of the day it's the (majority of the) parliament that enacts a given law, so in my book they are all responsible, even if in practice laws get written by a small subset of people.
I'm blown away by the hand wringing of this. Someone would be forced to answer for the way they voted and inserted language. It makes it harder to do what you complain about because someone is going to take a hit. If its a little guy he might lose the next election. If its a big guy, eventually these things add up. Not sure what unintended consequences might appear. It sounds like you are resigned to the worst fate right now.
In Germany Sparda-Banken and, I think, Volks- und Raiffeisenbanken support tap-to-pay through their apps. (And maybe other banks providing apps developed by the same contractor, Atruvia AG.)
PayPal also offers tap-to-pay, though I recently had to disable Graphene's "secure app spawning" feature for the PayPal app to get it to open.
If we want our bank to add suppprt for GrapheneOS and specifically for “tap to pay” on GrapheneOS, without Google pay, what technically and specifically should we be asking for?
I wish I had a good answer for you! I don't think there's anything specific they need to do for GrapheneOS. They "just" need to use Android's NFC API[0] and then do the necessary magic incantations to implement the relevant payment scheme, i.e. exchange data with the credit card terminal and talk to the bank's backend servers. How exactly that works… no idea. But if there's anyone who knows it's them!
There was a time when I thought about figuring this out in detail and building an open-source alternative to Google Pay. But from what I've heard, integrating with credit cards is not something that can be done in an agnostic manner but actually requires support and buy-in by the issuing banks. Not a great perspective for such an app.
At this point, it would be fastest/most effective for the PHP foundation to deploy their own white-hat mass hacking attack to exploit the vulnerability and forcefully shutdown vulnerable servers.
I can't think of a faster way to clear out the vulnerable surface area.
Yeah they should poorly set up a sandbox and ask it to fix all the vulnerable servers with the remote RCE and prepare to be surprised when it escapes the sandbox.
reply