notes

You could update Archlinux with pacman over ipfs from around 2015 until last year. https://github.com/ipfs/notes/issues/84 Then the mirror became too slow and couldn't handle the amount of package data and was shut down: https://github.com/RubenKelevra/pacman.store It worked rather well and even automatically mirrored the packages on my LAN. Maybe it'll be back some day.

Is there an easy way to comply with an accountable, non-oprressive-regime e.g. at least CSAM IPFS block list? "Implement Allow Lists and Block Lists" (2018) https://github.com/ipfs/notes/issues/284 "IPIP 298: (allow|deny)lists for IPFS Nodes and Gateways" (2022) https://github.com/ipfs/specs/pull/340

How do you manage access control with IPFS? Just because someone knows a hash does not mean they are allowed to access the content. EDIT: It seems [1] they want you to encrypt content and do access control outside of ipfs. Imagine ext4 telling you to do acl's on your own. To me, it is a little more than bittorrent without acls and at-rest confidentiality built-in. [1] https://github.com/ipfs/notes/issues/376

IPFS is not anonymous and like other p2p protocols shares your ip address. People seeding articles would get legal notices just like torrents now. There's been a bit of effort to get it working over tor for years now but the fundamental design makes this difficult. Also despite all the money that has poured into filecoin this doesn't seem to be a priority. This issue is nearly 6 years old: https://github.com/ipfs/notes/issues/37

If IPFS-over-Tor is in the development hell, IPFS-over-I2P is in the development limbo. https://github.com/ipfs/notes/issues/124

IPFS-over-Tor has been trapped in development hell for 5 years. https://github.com/ipfs/notes/issues/37

Here’s one written by an employee of Redis Labs about CRDTs for georeplication of databases for strong eventual consistency. [1] There's also 2-year old list of CRDTs used in prod [2]. I know Azure CosmosDB (NoSQL) advertises it's own use of CRDTs for global replication. [1] https://www.infoworld.com/article/3305321/when-to-use-a-crdt... [2] https://github.com/ipfs/notes/issues/404

[This](https://github.com/ipfs/notes/issues/208) summarizes it well. [Related.](https://news.ycombinator.com/item?id=18650670) TLDR: IPFS acts as a single swarm (i.e. universal deduping) and has more projects like IPNS, IPLD, and Filecoin under its umbrella. In my opinion, the project is more of an effort to evolve of decentralized technologies to a point where they can be used for mainstream products.

It seems global copyright enforcement with blacklisting and blocklists: https://github.com/ipfs/notes/issues/284 (I've testified in US federal court in copyright cases as the expert witness professor. I always try to investigate the DMCA decisions of developers. Difficult tradeoffs.)

IPFS has the same problems given a takedown notice[0]. Although you could continue serving the content and convince others to serve the content, any entity can take the next step and go after you. [0]: https://github.com/ipfs/notes/issues/284

There is a big issue, that ipfs uses its own hash mechanism (hash of protobuf of dag), while registries (and most other existing content based distribution mechanisms) use sha256 hashes of the whole content. eg see https://github.com/ipfs/notes/issues/269 So you can't simply interop between the two without some sort of lookup to convert hash functions. It is hugely frustrating, as basically different content based distribution mechanisms cant work together. In theory docker image registries support pluggable hash functions, although it is not clear to me that the ipfs function is even very well defined outside its own code. We could start to add a second hash calculation to every registry operation, but it would be a performance hit which some users would not like. (tree based content hashes that allow parallelisation are nice, but the ip

"just the cryptographic hash of that file" Is that strictly true? I am still wrapping my head around the DAG, but as far as I can tell, if I add a "large" file and you add a large file, they may result in different ipfshashes. Is that remotely accurate? More importantly, does it matter? Can I hand someone a 16cb96ba835448d441b02c50d783a0ea7b424df1 and expect them to be able to find the file? https://github.com/ipfs/go-ipfs/issues/1953 https://github.com/ipfs/notes/issues/126

So this is going into the land of RPC, have anyone work together on the load this would demand on a bigger scale than one man's $5 box. Already a seed of thought in place for this: https://github.com/ipfs/notes/issues/116

https://github.com/ipfs/notes/issues/37 is one possible solution to anonymous IPFS.

> they never really finished the pubsub implementation and js-ipfs still can't run in the browser because there is no IPFS network that communicates using WebSockets and not TCP/UDP I don't believe the pub/sub is critical functionality (progress at [0], but it's really just chatty). Progress of that additional feature should not be a measuring stick for the project as a whole. For js-ipfs, I see work being done frequently, e.g. the DHT work[1] and weekly syncs[2]. I agree work is slow, but I am not getting the impression it is fizzing out. Having said that, I think there are fundamental problems with the ideas behind it. I want MaidSafe's ideas and IPFS's completion/MVP schedule. IPFS doesn't bring enough anonymity or forced, equitable, encrypted block sharing IMO (I am aware of efforts on both fronts of course). 0 - https://github.com/ip