Hacker Newsnew | past | comments | ask | show | jobs | submit | jimpick's commentslogin

Dr. Booth (her late husband) was one of my engineering professors back at the University of Victoria back in the early ‘90s. It’s amazing that modern CPUs still use the multiplication circuits he created (along with his wife). Also one of several people that can claim to have created the first spinning magnetic storage!


People hating on IPFS DHT performance probably aren’t using the experimental accelerated DHT client. https://github.com/ipfs/go-ipfs/blob/master/docs/experimenta...


Probably because it’s experimental and is not mainstream yet.


“Disrupting data” sounds like a hell of a lot of fun.


You can see the live file storage deals here. https://filfox.info/en/deal


There isn’t really a single price. Each miner sets their prices dynamically (off-chain). Some miners set ridiculous prices to scare off load and some even set their prices to zero to attract test deal traffic. Miners have different reliability and business strategies too. If you look at average prices for asks or deals, it can be very misleading.


You can mine under 10TiB. You aren’t eligible for block rewards until you are proving at least 10TiB. Filecoin+ verified data deals count for 10x power. There’s a lot of power on the network, so the frequency of winning blocks at the threshold is fairly infrequent.


For long term archiving, it’s essential practice to move data from machine to machine over time anyways, as machines get old and obsolete and can’t be repaired after a certain age.

Right now there’s a maximum deal term of 1.5 years. Potentially that could be extended as the system matures and miners become capable of taking on longer commitments.


Security, mostly - if the proofs fail, it’s not just the data that could be corrupted - bad actors could attack the consensus itself and steal unlimited funds. The params for the proofs could be loosened, at the cost of extra risk of an attack. They’ve gone the safe route and picked challenging parameters that would be uneconomic to brute force attack.


Take the total storage size on the network, figure out the number of spinning disks, multiply by the power consumption per disk + typical overhead for servers and switches, etc. There’s power consumed by the processing for proofs on data ingest (bigger miners are more efficient at this), but not much afterwards.


I've been doing some experimentation along the same lines ... I've got a small proof-of-concept working where I can sync Earthstar databases between multiple Sandstorm instances - each "grain" acts as a pub, and you can use "webkeys" as pubs. I'm using powerbox-http-proxy to request capabilities for connections, so it works even with fully sandboxed client-side networking (ALLOW_LEGACY_RELAXED_CSP=false). It's maddeningly complex to do simple networking, but it's amazing to have the security layer there. I'll put together a blog post / video soonish.

https://github.com/jimpick/sandstorm-earthstar-foyer

Sandstorm is very interesting for privacy-focused peer-to-peer because it has the tools in place to sandbox networking. The networking security model is designed to prevent things from talking to each other without user approvals - so it's extra tricky to do peer-to-peer things with it.

I'm excited to try to stick some of my old IPFS/IPLD/libp2p/Dat/CRDT things into Sandstorm - there's a tonne of interesting things that could be done with it.


I was wondering about that. I suppose, things that the user wants to share publicly can be done so (via powerbox), but otherwise, everything else would not be.

Are you using the grain model for each individual files to be shared?

(I looked up your email and I would like to continue chatting about this).


Everything is in a grain, but I think the Earthstar applications could be decomposed to just handle a single document at a time.

I made a quick demo recording and updated the README with a link.

Video is here: https://bafybeih6kkv4rgmfada4kfc5thmtzheiurq7ck5uz4rchqkrxw7...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: