100 karma · joined May 14, 2018
I have had to make changes to the build system for the React system I maintain at work, but in no way would I consider it a "rewrite", as much as a "refactor" for a specific part of the codebase while leaving the rest relatively untouched.
In fact, JavaScript moving to ESM has broken MUCH more code than any of the React features listed in the article.
Has there been any movement on migrating away from long polling (#475)? I didn't see anything about it in the announcements or comments despite such a big milestone
If a program is able to predict this once or twice it's not a miracle. If it's able to do so with 60% I'd raise some eyebrows. But I'd say it's only a turning point when it's able to beat false positive rates of human doctors. Without an accuracy score, this news is absolutely meaningless.
This is not exactly true, it just means the server that holds ur data (traditionally instance or home server) doesn't need to be involved in the transfer process. However, this has centralized identity resolution, which is not a good long term solution.
> For example, someone was able to get the AWS S3 domain as their handle!
This is easily hotfixable by requiring more stringent proof of ownership of the domain (like DNS records), rather than a problem with the protocol itself. But it's a valid concern
> But runs into the problem of algorithms being hijacked to show inappropriate/offensive/bigoted content.
I thought the whole point was that if you didn't like the algorithm you could swap it out for something simpler. This point puzzles me greatly
> that could’ve just been extensions to the ActivityPub protocol rather than a whole new protocol!
Not really. If you peel back the interface they're very different, since the transferability of accounts across servers is something baked deeply into how ActivityPub works and cannot be easily changed without rewriting the protocol. That being said, I personally hope there is some network that can solve the problem of untying resources from domains, since it is one of the big problems with any federated protocol
- the password validation fails for reasons not listed entirely
- the password box truncates passwords silently
But on the other hand, the AT protocol is not all what it seems either. It's fundamentally not possible to do what they promise unless there is some kind of synchronization point where your most up-to-date identity can be searched. The documentation goes on extensively about the format of DIDs and the fact that there _is_ a resolution scheme, but it fails to mention that this resolution is being done by Bluesky themselves, and is not planned to expand into something that others can control. As a decentralized protocol, you would expect this to be something DNS-based, or if you really wanted something more peer-to-peer, DHT lookup, or at the worst case, a distributed blockchain. Seeing as this is a fundamental protocol-level change, the fact that they're rolling with the current approach makes me believe they will not be changing this in the near future. Bluesky is just converting one problem into another.
> the right to store, archive, parse, and display Your Content, and make incidental copies, as necessary to provide the Service, including improving the Service over time
It's insane how vague this is. Is Copilot a "Service"? Sure, by its definition:
> The “Service” refers to the applications, software, products, and services provided by GitHub, including any Beta Previews.
And since much of the code was published before Copilot's inception, this means Github can just arbitrarily add more "services" and milk the code for whatever it wants. Automatically service-ify any public repository? Sure, pay us for quotas. It's like a legal loophole to let Github just bypass any license restrictions you put on it.
- Unix time converter: (unixtime) => new Date(unixtime)
- Unix time converter reverse: (date) => ~~(date.getTime() / 1000)
- JSON prettifier: (jsonString) => JSON.stringify(JSON.parse(jsonString), null, 2)
- JWT debugger: doesn't exist in browsers i suppose
- Base64 encode: btoa
- Base64 decode: atob
- Query string parser: (queryString) => new Map(new URLSearchParams(queryString).entries())
- HTML entity encode/decode: idk why u need this, should not be escaping html manually in webpages just use .innerText
- Backslash escape: not sure what specifically this is doing in the app but sounds like it's easy enough to do it with a regex
I feel like if u want a UI u should make one that can save scripts and turn them into forms so that users can add arbitrary functions themselves without having to wait for the application to add more functionality
It's better to spend just a couple minutes setting up a static site generator into your workflow than to have every user who pulls up your STATIC website perform template rendering and all that garbage. I know computers are fast and it doesn't seem like it really makes that much of a difference, but thinking like this often leads to inefficiencies in other applications as well.