That is great stuff and sounds really interesting. Thanks @aschrijver!
As I see it, Solid is an interface to the web which appears as a file system, accessible through http, so it is a file system with content negotiation.
Behind a Solid interface might be different things. The ‘files’ might might not actually be files at all, but parts of a database. Or a mix of files and parts of a database. They might be local to the http site or remote from it and accessible by the site through http or maybe some other protocol. The http site itself may be an internal local server or a remote server.
So Solid does not necessarily use remote servers and it can be used to abstract a server-less network too. Solid can be a bridge between the current http web and current or future networks with different protocols. @happybeing has shown that this is possible.
Solid may not only be a bridge to those new protocols, but it may also provide interoperability standards that applications for new protocols will need in order to be compatible with each other.
It also makes sense to me that, while servers may not be a good idea, it still makes sense to describe services out there on a server-less network. This is like making recipes only in your local kitchen, but having a lot of recipes available out there, even if no ready made take out is available.
Because Solid is an extension of the current web, but can also act as a bridge to new protocols, it makes sense to me to develop on Solid in order to future proof an application.
The other thing that makes Solid attractive in the context of community currencies, is that by modeling everyday human interactions more accurately than the current web, it allows for a lot of flexibility in terms of how communities can develop. This is also true of other standards such as ActivityPub, but without the bridging and interoperability abilities described above, ActivityPub by itself is not enough and will be best used together with Solid.