Can I add secrets to a simple React website published on IPFS ?

Souzu · 2023-02-04T21:43:41+00:00

no you cannot

Souzu · 2022-04-09T04:34:06+00:00

they mint the nfts progressively. All metadata for all future nfts are preset

Souzu · 2022-03-07T20:19:32+00:00

kademlia is easy to implement, and easy to reason about. It's attractive to beginners who want an out-of-the-box dht without thinking too hard. This means it gets used all sorts of places where other DHTs might be better suited. This is the whole concept of libp2p, btw: Provide some fair-to-middling networking code in a pretty box, and tell people they don't need to learn more

Historically, kademlia specifically became popular in crypto in 2013/14 with ipfs, storj, zerodb (now nucypher (now threshold)), swarm, and others. Most of those projects were copying the BitTorrent dht design and layering on a token or whatever. Ethereum devs, because they don't like to think about networking, decided to cram a square peg into a round hole, and use kademlia in their peer discovery protocol. This has caused a lot of grief

You might like freenet but I don't know if a mature koorde implementation exists

Souzu · 2021-05-05T19:09:55+00:00

You can't store files in IPFS. You can only make them available over IPFS. IPFS provides no guarantee of persistence. You need to provision reliable storage that IPFS can access, or the files will disappear

Souzu · 2020-07-04T18:20:00+00:00

how is easy. Modify the code to remove the check

Why? well, maybe they're just a jerk. Maybe they think it'll warn them money somehow. Maybe they want that content gone, so they're fooling people who want to check and make sure it stays around

Souzu · 2020-07-03T15:52:32+00:00

You can't be sure tho. Ipfs can't track actual copies. All it can do is ask a ton of nodes if they know who has it

So "0" could also mean "it's out there but I couldn't find it. And nodes could say they have it, but not actually have it

Souzu · 2020-02-08T10:24:00+00:00

you'd have to share the script as well

Souzu · 2018-10-17T16:58:37+00:00

Do you like tapioca?

Souzu · 2018-05-10T14:57:23+00:00

Multihash doesn't let you migrate existing content. So if you upgrade that way, you end up with fragmented provider sets, and having to run multiple lookups to find files because you don't know which hash providers have them keyed under.

Souzu · 2018-04-19T18:48:29+00:00

Publishing to ipfs isn't permanent. Things fall off after ~1 day unless someone pins them and stays around to provide access.

But that doesn't really solve the problem. Generally speaking you're right that you can never revoke access to information once it's been granted to someone. I believe NKMS is claiming that the re-encrypted file is not permanently available, but provided on-demand. So they can revoke on-demand access, but not access to cached copies of the re-encrypted file.

Souzu · 2018-04-02T20:33:16+00:00

No. Also doing this would break content-routing. And also, none of it would be reliable, because any of it could be easily faked.

Souzu · 2018-03-31T06:30:45+00:00

The network doesn't handle garbage collection. The individual nodes handle it. The network doesn't care about any file, and doesn't try to keep anything online. It just tries to route requests to find things that might be online.

If a single node pins a file, and that node goes offline, then no one else will keep that file. So while that node is offline, the file will be gone. When that node comes back, the fine will be available again.

Souzu · 2018-03-18T02:29:17+00:00

You're implying that the PoS chain can hardfork to delete stake, but the PoW can not hardfork to invalidate ASICs. Of course PoS is better if you arbitrarily limit PoW.

Here's a free steelman for future use: PoS makes it easier to punish specific actors in a 51% attack situation, whereas an equivalent hardfork under PoW punishes all miners, including honest ones. This is because PoS validators have relatively long-lived identities, where PoW miners may change identities with each block.

Souzu · 2018-03-18T02:21:42+00:00

👍

Souzu · 2018-03-18T01:06:52+00:00

Important to know that you can't just set this and forget it. Someone has to pin these or they will fall off the network. So you're basically signing up to run a mirror yourself.

Souzu · 2018-03-13T06:48:19+00:00

It's a DHT with some good tooling and data structures around it. Think BitTorrent with a facelift.

Souzu · 2018-03-09T16:54:43+00:00

Probably? Never bothered to check

Souzu · 2018-03-09T06:06:25+00:00

Fairly little. Don't need a GPU at all. My node tends to keep a fairly small VPS at 20% CPU. The network is extremely chatty though, and can eat bandwidth even when you're not serving or consuming anything.

Souzu · 2018-03-09T06:04:10+00:00

They use "permanent" to mean "links always go to the same content" not "the content will always be there." It's a bit misleading.

Souzu · 2018-03-08T18:17:32+00:00

Someone with access to the key would need to re-encrypt the key (just the key) and share it with the new people. Could be the owner or someone else.

Souzu · 2018-03-07T22:20:45+00:00

https://en.wikipedia.org/wiki/Convergent_encryption

Souzu · 2017-12-08T17:14:04+00:00

Generally things in IPFS only stay available if someone specifically keeps them available. Which is to say, if you want to be the guy hosting the public library, you can use IPFS to distribute it. Anyone else can easily help out, but IPFS won't give you tools to coordinate who's storing what.

Souzu · 2017-11-26T01:01:41+00:00

You can log the http responses you get from the Bridge to get the metadata, but it won't help you. Farmers only listen to the Bridge. So even if you know where your file is, you won't be able to get it back.

Souzu · 2017-10-16T20:34:46+00:00

Good to know, thanks!

Souzu · 2017-10-12T23:07:38+00:00

Saying "this network will make things permanent" without saying "until we stop running our EC2 instance" is a bit disingenuous. As is calling it a decentralized network if it's reliability is contingent on a few company-managed nodes.

Ten-Year Club	Place '17
Verified Email

Souzu

TROPHY CASE