willscott

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.

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.

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.

It defaults to a high port. when mounting, you can pass options to set both NFS and MOUNT port and skip the portmapper.

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.

Wasn't expecting to see this here!

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.