What else does Oracle have? Mostly just a bunch of IP that a sufficiently strong AI will be able to recreate for a fraction of each customers bill. Oracle is very aware.
Where is the value coming from when all knowledge work (and later manual work) is 10-100-10000x cheaper done by AIs? You probably don’t want to build models, too easy to move to another provider when one is better, open models eat your lunch etc. But there are still means of production to be owned but it’s just GPUs
This looks cool - however, I had a hard time understanding what I can use xbin for. I feel like it would be better if the landing page, or the GitHub README talked about what xbin enables me to do first, and then talk about the technical bits.
Yeah I’m still iterating on the pitch and target audience, thanks for flagging.
It’s not a general coding tool, shortest description would be “personal/company data/process management layer” or “everything a company may want an on-prem datacenter and admin (dev)team for, accelerated by AI”.
Came from finding bug shortcomings in OpenClaw/Hermes where it’s not really close to having everything needed to organise and deal with big data in a safe or efficient way.
Basically the bottleneck is building a massive amount of software around agents which won’t happen in an all-in-one harness, this attacks that problem
I run a company currently serving ~1.7B requests per day (~20k/s) to ipfs gateways, so presumably still some. Very likely a big chunk of that is bots scraping stuff.
Sad to see it go having been a maintainer some years ago.
For anyone wondering, there are more sustainable (with a viable, focused business backing the project) options to do p2p, namely Iroh - https://www.iroh.computer/ which was built by ex-IPFS ex-Protocol Labs devs (I have no relation to the team beyond having worked with them back in the day).
Sadly Protocol Labs is doing.. ehh whatever now, except apparently supporting the projects it got its VC/crypto funding from.
Iroh is great! As is ATProto! Both build on DASL (https://dasl.ing/bdasl.html) - which specifies the core content addressing layer of IPFS.
However - important clarification about the Shipyard post that I think a lot of folks are confused by:
While its sad to see the Shipyard team sunset, the IPFS project is decentralized & robust to a single party moving on. IPFS the project/network is not sunsetting or shutting down!
Current focus is lighter-weight stewardship from the IPFS Foundation via grants to individual maintainers, & development of decentralized public infra tools like the Service Worker Gateway.
You are describing Protocol Labs' plans in the first person, as "current focus". If you work there, please say so in the comment. On a thread about Protocol Labs ending the maintainers' funding, that context matters to anyone weighing the reassurance.
DASL specifies CIDs, CAR and deterministic CBOR. It deliberately does not specify UnixFS, and it has no way to chunk a file into blocks. UnixFS is what ipfs add has produced since 2015, and what Kubo, Boxo, Helia and the gateways address today. So DASL is the naming layer, not "the core content addressing layer of IPFS". Writing a new format is easy. The stability people built on came from not rewriting this one, and from someone shipping it in the software they already run.
I run Kubo and Helia in production. "Robust to a single party moving on" would be easier to accept with answers to these:
- Who triages vulnerability reports and ships fixes for Kubo, Boxo and Helia after September? Does the contact in https://github.com/ipfs/community/blob/master/SECURITY.md still reach a person?
- Will anyone cut releases, or should operators pin current versions and plan around that? Should we expect a community fork?
- Who operates ipfs.io, dweb.link and delegated-ipfs.dev day to day after September, and with what experience running public infrastructure at that scale?
- What happens to the Service Worker Gateway at https://inbrowser.link ?
- What happens to Badbits at https://badbits.dwebops.pub ? Does it stop being updated when Shipyard turns the lights off?
A grant to an individual maintainer is not the same as a named owner with commit rights and a release process.
On the Service Worker Gateway as decentralized public infrastructure: the subdomain gateway spec requires a wildcard TLS certificate for the ipfs and ipns subdomains, plus a Public Suffix List entry so each CID gets its own origin. You also need a denylist, or you end up serving phishing. Very few people reading this thread can self-host that, and the ones who try will meet the abuse problem next.
The same questions are open on discuss.ipfs.tech. A direct answer there would help more than reassurance here.
The way I would put is as: Iroh + iroh-blobs == libp2p + UnixFS + Bitswap, and the latter three are some of the critical components that have defined most IPFS implementations.
Iroh got started with IPFS-style content-addressed blob transfers as the primary way to use it, still has that functionality but its now a bit of a second tier citizen. See https://docs.iroh.computer/protocols/blobs
Besides just p2p streams seem to be much more useful, those are plug-and-play into most software, e.g. I wrote https://github.com/magik6k/git-remote-iroh that just plugs the git remote proto into iroh and lets you move repo commits between computers by just copying a string from one place to another on push. Doing that with blobs - not gonna happen, not that easily.
We realised that there are many more use cases for p2p streams than for blobs, so in the last year we have focused on getting iroh to 1.0, which involved implementing our own multipath QUIC implementation based on quinn. This was a lot of work and took the full focus of the team.
That being said, we plan to continue to work on blobs and get it to 1.0, which will involve some API changes and some internal changes, primarily to the blob store.
The blobs network protocol itself is just BLAKE3 verified streaming with a few tiny modifications (chunk groups) for efficiency, and hasn't changed since 2 years. Not because we don't have time for it but because it is done.
My personal goal is to have blobs working so well that you can forget about it, and also provide a solution for global content discovery.
All the protocol needs at this point is a DHT and a standard representation for directories. Everything else like data storage layouts and node trust systems can be handled client side.
This. Haven't seen this in the news in years. A few years ago (2022?), they got some $x00 million in investment money. They already had IPFS/IPNS at that point so it was some deep push into Filecoin. But it felt odd at the time. Bitcoin was starting to jump the shark at that point and none of the smarter cryptos had truly found a market fit either.
Love DASL (funded by IPFS too)! Iroh also meets the DASL spec (https://dasl.ing/bdasl.html). A great bridging opportunity for agents to build interop between many different content addressed systems!
There is one thing we do not have yet - global content discovery. The reason for this is that so far we have not found a way to do it in a way that just works.
It is a very hard problem, but I hope we can come up with a solution so we can cover the use cases that initially got me excited about IPFS many years ago.
The way I would put is as: Iroh + iroh-blobs == libp2p + UnixFS + Bitswap, and the latter three are some of the critical components that have defined most IPFS implementations.
I've seen some product prototypes using Iroh and it appears pretty good for "just get edge device / node connectivity to work" when you don't want end users to bother with networking shenanigans but can guarantee Internet connectivity.
Basically Tailscale but embedded into the app without the hassle of requiring users to setup accounts.
I really wish Moonlight would use Iroh. I use Tailscale to make it work, but it would be so much easier to just pair a machine and have it always work.
IPFS, Freenet, and experiments like that mainly serve as a place for people to store and distribute pirated copyrighted material, child porn, hit lists, terrorism manifestos and plans, and the like.
Scratch a libertarian and, nine times out of ten, you'll find someone who advocates for no or minimal government because they want to do something the government legitimately bars them from doing. Scratch a libertarian decentralized P2P E2EE communication project and you'll find... well, this kind of material nearly every time.
Your local computer hard drive can also be used to store all of the above. Are you also okay to make it scannable by anyone?
Worse you can store child porn as paper pictures in your house and can privately communicate in there with other unknown people and mignt even be do something illegal there. Do you want to install some police security camera in your toilet?
Oh, and in some countries being LGBTQ+ person or political activist or women right activist is illegal and will land you to execution on chop chop square. Should we also let all the governments find these people too?
> a libertarian decentralized P2P E2EE communication project
Your argument makes sense for Freenet (though I'd personally defend that project too); but not so much for IPFS.
Firstly, IPFS doesn't have any encryption (E2E or otherwise).
Also, Freenet spreads data around the network (for robustness and plausible-deniability), so the peers providing a file are not the peers which inserted it. IPFS does no such thing: if you want your content to remain available, you'd better be running an IPFS node that provides it.
Either way, it feels like a pretty bad idea to host dodgy stuff on IPFS.
IPFS is much closer to HTTP. The difference is that content is immutable, and can be re-hosted by anyone that happens to have a copy (e.g. no need for mirrors, etc.).
(Note that HTTP was invented to disseminate physics research; not CSAM)
Zen has completely different memory controller IP (UMC), that's configured at boot by AGESA/PSP. I doubt this exploit applies to modern Zen CPUs, however AMD are the only ones who could really confirm this.
Likewise -- also had zero issues going over this with Sol. Seemed to give solid advice for how to test it -- use an expendable bare-metal AMD family 16h test system w/ usual standard checks that apply.
> Run `platform_check` first and do not use `SKITTER_FORCE=1` casually. Start with the read-only `dram_state` and `dram_carveouts`, then `dram_dump --dry-run`. Avoid `dram_poke` until maps have been freshly collected and calibrated. Do not bypass fingerprint checks, calibration, fencing, or verification.
Claude's (apparently externally-mandated?) lobotomization continues to be concerning. :-/
You mean, completely self inflicted? "Ohhh government, guess who had the most dangerous model now... tee hehe We've been so baaaaad. Look at all these companies we accidentally hacked. Whoopsee."
1) Don't give your guests access to the DCT control registers.
2) On 15h - no obvious way. I don't know the other families.
3) Yes -- this can be verified easily. Pick up the AMD 15h BKDG, look up BankSwizzleMode. It's documented. The one oversight is that this bit is not under the Dram Controller's lock bit.
When Chris Domas left Battelle for Intel years back, shortly after hardware-fuzzing a bank of thin-clients to discover undocumented x86 instructions, I was convinced Intel was basically keeping him on the payroll to shut him up.
One hopes that a hypervisor would not expose hardware control registers directly in the first place, except ones deliberately designed for virtualization support.
Otherwise, the guest is running effectively at the same privilege level as the hypervisor (that's useful sometimes, but probably not intended in most applications).
Ok, on 2. and in general this exploit only works on pre-Zen AMD platforms as the repo states in not-so-clear terms.
Zen changed DTC (DRAM Controller) to UMC (Unified Memory Controller), UMC is programmed at boot, and one would hope they figured that locking access to it makes sense when they were adding confidential compute support; Not clear though because there is no public documentation on it, so best we can hope for is some statement from AMD/3rd party researcher saying "this won't work on Zen because X/Y/Z"
With respect to 2), I don't think this should work architecturally even if the DRAM controller has knobs which can be accessed, because the guest's RAM should be encrypted with keys that can't be recovered in this way.
It's definitely a good research topic because there are a lot of moving pieces and having this kind of primitive might weaken one of them in a useful way, but at least at the top level, you couldn't just swap one guest's DRAM bank with another and get their confidential memory contents back this way.
Has egress and ingress filtering, egress can be bound to host/internet/subnet or even better to internal apps (which are each separate netns) meaning you can do your own firewall/vpn/whatever per sandbox. Plus you control what other components in the sandbox env the app can communicate with.
Really not built for day-to-day dev work though, more like automating your company/life / getting rid of SaaS (e.g. for technical Founders / Sales etc, not exactly useful for dev work)
I did try to use those for some stuff:
* Login requirement is something else
* It's closed source last I checked
* Pretty slow/unstable
There are many better namespace/container based options, VMs may be moderately more secure but when you more or less trust your agent and code you can do with lesser containment. And with the recent CVEs in kvm honestly there isn't a huge deal of difference vs namespaces.
(I'm building https://xbin.dev/ for some time now for managing my personal code/apps, a project which started specifically after Docker Sandboxes broke on me some time ago)
Where is the value coming from when all knowledge work (and later manual work) is 10-100-10000x cheaper done by AIs? You probably don’t want to build models, too easy to move to another provider when one is better, open models eat your lunch etc. But there are still means of production to be owned but it’s just GPUs
reply