Bryan touches on an important axes in the question of how to structure decentralized networks in describing sharded search as "too risky to build on today."
Designs that a team thinks will be able to scale are going to be different from the ones built in a fully satisfying decentralized way. It's the prototyping and experimental networks that can help pave the way for more decentralized systems to get built with the intention of scale.
One of the points that is made is that since the PDS that's being interacted with here is part of a 'Personal Data Server' rather than the Bluesky product, it ends up able to offer infinite free data storage.
This seems like one of the things that might be part of the references the bluesky team has made at time to introducing a subscription service - providing more space / bandwidth / higher quality video on your PDS seems like the type of hosting that could be offered at a premium tier.
This was a fun project. It's good to know that a lot of the north korean consumer technology does propagate at least to the border areas with China, and so has a chance to be archived and kept available into the future.
Likewise, the 'essentially the same' drand is a 2017 paper https://www.ieee-security.org/TC/SP2017/papers/413.pdf and the league of entropy has been running since 2019, so hard to know exactly what the additional pioneering was in 2021.
counterpoint: less disenfranchisement, actions to honor the popular vote at the party and popular vote level (see: super delegates, electoral college, state representation), perturbation of the 2 party system to allow representation of positions held by young people would all be _actions_ to cause more people to vote, rather than telling people to stand in lines in badly gerrymandered counties with insufficient services. At some point, people loose trust in the system. Gallop polls from this year indicate that 60% of Americans do not have confidence in the US election system [1].
It would be super interesting to overlay the scale of efforts like this one that follow publisher licenses with those of scihub that ignore them.
The amount of effort we put into curation due to license and the amount of content lost because of our ownership policies seem to be coming more clearly into view as we consider the costs those choices incur.
for the last month (v6.6.0 and v6.7.0) libvirt has been released with a new key 453B65310595562855471199CA68BE8010084C9C (first seen:2020-07-20).
It hasn't been signed or verified by any other source in libvirt / redhat yet.
https://www.redhat.com/archives/libvirt-announce/2020-July/m...
That is preventing downstream distros, like arch, from admitting these new releases into their package repos.
V4 has many more things going on (it's stateful, has a much more complicated locking system integrated, and adds some other points of complexity that get better performance).
More than I was ready to take on for a first pass :)
Most testing has been on a Lan or on the local machine for local VFS use cases.
This layer eschews responsibility for multiple concurrent clients for simplicity. No promises you'll get either decent performance or proper cache invalidation when using it that way. It tends to be conservative in not filling in all the opportunistic caches.
There's a hook the backing application can use to tune reads and write sizes that becomes much more relevant in a network case. How those should be set in practice isn't something I've spent time on.
one of the major attractions of the fuse abstraction layer is that once you have fuse you can interact with more exotic file system types without having to deal with new kernel drivers each time.
Instead though, you can translate the exotic file system types to nfs, and use the existing kernel drivers that already exist for mounting an NFS mount.
This turned out easier than i was expecting it to be. It's nice to be able to mount a VFS without needing privileges on the server side.
The main intention for this code is to eventually use it to replace fuse on mac, since nfs is a valid mount time for mac clients to consume.
Censorship / availability is the issue. As you lay out, Sybils can be used to target a specific address / piece of content in an attempt to prevent it from being found. The good news is that there are some pretty mechanical things - like maintaining a consensus of known-trusted nodes that can be used to validate a node/piece of content isn't under attack - that should be sufficient until IFPS is quite a bit larger than it is today
I don't think I see the impersonation / bad resolution problem though. IPNS records are content addressed to the key. Having control of a portion of the network isn't sufficient to compromise that (you can prevent availability though).
For BGP partitions / Significant network outage conditions:
You may not find content partitioned on the other side of a netsplit from you, but the degraded condition is that you can still query and find content present in the same part of the network as you. This is better than centralized solutions face at present - e.g. google not being available in China, and isn't too far off from what you might hope.
For Sybils:
You've left the attack you're worried about pretty vague. IPFS itself doesn't need to tackle many of the sybil-related issues by being content addressable (so only worrying about availability - not integrity) and not being a discovery platform - so not worrying about spam / influence. For the remaining degradation attacks - someone overwhelming the DHT with misbehaving nodes - there's been a bunch of work in this release looking at how to score peers and figure out which ones aren't worth keeping in the DHT.
The release notes contain a pretty extensive list of what APIs have changed.
The path to upgrade the dependencies is probably to run `go get -u <dep>` for the direct dependencies you're including, and then fixing errors that pop up from doing so.
IPFS is actually a better fit for this than it might appear.
It doesn't pro-actively replicate content, so it isn't like bit torrent where everyone is uploading.
Instead, it provides resilience, where the actual location of sci-hub could move around, but requesters could still get access to the content. The rest of the network acts to help with routing, but won't be serving data they haven't accessed themselves.
https://repeatr.io/welcome/what-is-timeless/ explains timeless as a set of tooling for reproducible builds with a broader and more hash-based mandate than what's out there currently. While early, it seems like it's a reasonable path towards getting a reproducible system that won't fall apart as fast over time, by vendoring the dependency system in the same way modern language-specific package managers do, but at a language-agnostic/distribution level.
Designs that a team thinks will be able to scale are going to be different from the ones built in a fully satisfying decentralized way. It's the prototyping and experimental networks that can help pave the way for more decentralized systems to get built with the intention of scale.