Been a member of the remotestorage and solid projects since the start. I am hoping to port the best parts, to nostr, and fix a few of the bugs along the way.

Actually I helped develop a pub/sub system over websockets for solid. But it has bugs. It was quicker for me to work with fiatjaf to get nostr in good shape, that it would have been for me to get solid patches upstream, which I've had working since 2017. Hopefully it will all converge.

With any luck, I'll get some more time to develop NosDAV, however some of the important parts are working, and I use it all the timer already:

https://nosdav.com/

I am aware of Nosdav, but I don't appreciate its dependency on Nostr spec for no reason. For example Pkarr HAS to be ed25519 because Mainline DHT is the value proposition and it requires such. Nosdav has no reason to be using (exclusively) neither secp or the Nostr event spec.

But these are the least of the problems, the bigger issues are:

- No search or range queries API (only stores files not kv store)

- No collections/folders or any scopes

- obviously no read access control because there is no scopes to enforce access control on

- no write access control that supports multiple keys on multiple devices, so again inheriting Nostr choices that are recently forced the creation of custodial services like nsecbunker

- no efficient sync with other servers or local nodes (to enable local first and offline first apps) even though Strfry adopted such algorithms after I shared that paper with Hoytech

- while it maybe out of scope, but investments in client side encryption SDK is absolutely necessary to make it e2ee (including filenames) which is important for privacy and minimizing risk to servers providers getting hit by content laws

I love that Nosdav is much simpler than DWNs and embraced REST, but we need to do better, and that we can without much complexity.

If I would use one sentence to describe my issues with it: it doesn't do enough to support local first apps, which is a step back from Git.