Logo pending™

Private Communities

(This document is not part of the ChiFS protocol specification. It describes a possible future extension of ChiFS. See the protocol overview for context.)

With the current model, each Share is public and is sharing all of its files with anyone who might be interested in them. A Share announces itself to one or more Hubs, but those Hubs are not necessarily the only ones indexing that particular Share. In fact, it would be relatively trivial for a Hub to fully clone another Hub: Just grab a list of all Shares from the Hub and index those. A Share has no way to restrict which Hubs are allowed to index it and/or who is allowed to download from it.

Reasons for wanting to restrict access to Hubs and Shares could be:

I consider this out of scope for the early stages of ChiFS, but support for private communities can be considered if there's demand for it. Here's a rough idea of how this could work.


Precondition: Users have a way to register and authenticate to a Hub. Plain old user/password authentication would suffice for this model, but stronger schemes could also be supported.

The Hub generates a public/private key pair and makes sure that the public key is available to all Shares indexed by the Hub. Users that wish to download a file from a Share first obtain a token signed by the Hub's private key, which they can then use to authenticate themselves to a Share. The Share can verify the validity of the User's token by checking it against the public key of the Hub.

A User's token should be short-lived, anywhere between 5 minutes and 24 hours should suffice, depending on the Hub's policies. A short expiration time ensures that Users will have to regularly re-authenticate themselves to the Hub and limits the amount of time that a user can access Shares after their authorization has been revoked. Short-lived tokens also avoid the need to implement systems like CRL or OCSP.

Tokens could be restricted in various ways: