pull down to refresh

- Why Java
Why not? It is one of the best languages for this.
- Why NIP-DC over something like FIPS
Nostr4j p2p stack is older than FIPS and it is to create p2p apps, not to proxy existing traffic. Nostr4j's p2p was also built specifically to sustain games' netcode (as part of ngengine work) so it has some features and optimizations needed for that,
eg.
- it prefers lower latency direct connection (as opposed to the mesh route) when possible, since in most use cases peer count will be low enough to connect to all of them directly
- has little overhead on both the rtc route and the TURN fallback
- lets you build unreliable chanels
- runs on the browser and natively on every other platform
It is my own take to p2p networking
Unless I missed some big change in the way Visa operates.. this cannot be compliant... they are going to kill it as soon as people start using it.
This is very odd, and I'm not saying this is necessarily the reason, but a smart person in bad faith would do exactly something like this if there were a few tweets that weren't obviously incriminating, but that they really wanted deleted without drawing attention to them.
It proves nothing, of course, but it is not a good look. In fact, it may be the worst possible look IMO.
Influencers (and NVK) should figure out a way to reimburse their followers that got rugged.
Bugs happens, but promoting a device (built on clearly questionable DIY stack) as if it was better that everything else, while having all the tools (ie. opensource code) but not the knowledge to verify the claim, is something else.
Hopefully this is the end of the bitcoin religion, and we can go back at ignoring influencers and using bitcoin as money.
I am a quantum negationist, but if this makes quantum and other pseudoscience believers happier to use bitcoin, then imo it can be a good idea, there is too much money behind quantum propaganda to even try fighting it at this point...
But IMO, there is no need for a 3 phase update, actually this is a bad idea.
Phase A should be skipped entirely, as it will be unpopular and it will only make bitcoin shittier to use, until all the libraries and software catch up.
And B and C should be rolled out together.
Knowing there is a breaking change incoming, libraries and software will naturally migrate to the new consensus.
Well, let's say it is less likely for a big cloud provider to leak customers chatlogs vs a random node on the internet.
I think for this to be somewhat a little bit more private, you could run as many layers as possible on the user machine (or your centralized gateway) and then offload the rest to a group of nodes, so that a single node does not run the inference from start to finish.
I'm new on stacker news
Welcome! By the way, I noticed your reply only because you've sent the zap.
Since your comment was a freebie it was hidden automatically, you should connect a wallet or buy some credits on sn to make sure you reach people you reply to
How do you prevent untrusted nodes from decoding and logging the prompt sent by the users?
How do you prevent untrusted nodes from sending garbage outputs just to receive the payout?
The MalusCorp Guarantee™
If any of our liberated code is found to infringe on the original license, we'll provide a full refund and relocate our corporate headquarters to international waters.*
*This has never happened because it legally cannot happen. Trust us.
"I used to feel guilty about not attributing open source maintainers. Then I remembered that guilt doesn't show up on quarterly reports. Thank you, MalusCorp."
This is a parody 🗿.
Opensource licenses are on an honor system, anyway, the real deterrence is reputational damage when it is found out
Funny concept 🗿i am like at the edge of the city
but stats are a bit broken, because it doesn't count org stars etc.., your building would probably be much higher
They do, but these are likely CI builds. These builds run on containers/vms spawned from scratch for each commit, they build, validate, publish (if a release) and then self destroy.
It is a good way to avoid any possible cross contamination between builds for security and reproducibility.
Caching here, without compromises, can be quite complex depending on the underlying system, and might require a custom build script for CI, that is often undesirable, because ideally the CI build should follow the same path as a manual build whenever possible, so it can also catch bugs in the build script itself.
The people complaining about this are the hosts of Maven Central (Java's npm), and they caused this themselves by pushing for Java build centralization. You can configure a project to use any Maven repository in Java, but it is so inconvenient and looks so suspicious or hard to verify that everyone ended up publishing to Maven Central, going through all the annoying hoops they put in place. Somehow they did not consider that they would have to host the entire world?
I think we need a nostr alternative: metadata signed and curated on nostr, payloads hosted on the dev own servers.
Before people running this start complaining to @sox and @k00b about the site being slow…
This fires on every DOM mutation (often multiple times per load) and queries the whole document each time. With many live comments and huge threads, this can be a problem.
At the very least, the observer logic should be debounced and only act on newly added nodes.
This doesn't look like a vulnerability, but a patch to revoke the indian CA certificates that were found to be generated with a weak key, more info here: https://openjdk.org/groups/vulnerability/advisories/2026-10-21