search

inrupt / pod-server

Solid server package that bind together solid-idp, wac-ldp, and websockets-pubsub.
MIT License
40 stars 12 forks source link

support custom domain names #20

Open michielbdejong opened 5 years ago

michielbdejong commented 5 years ago

The pod server should host one storage area per FQDN. Need to decide how we store root ACLs and quotas. This question is separate from the question of how the IDP links username/password to WebId, but the answer to those two questions could be one single database.

@jaxoncreed let's brainstorm about this today when we have a minute.

michielbdejong commented 5 years ago

So assuming there's an external database (e.g. LDAP) holding login details per username. We can have a standard mapping from username to WebId & pod-root. Then the RdfLayer of wac-ldp needs to know all the hostnames that are local. In the simple case we can say pod-root is always https://<username>.podserver.tld/ and WebId is always https://<username>.podserver.tld/profile/card#me.

Quota can be checked by a daily cron job, plus a server-wide sysops alert when the storage is 80% full, 85% full, etc. That allows you to take a day to go over quota, but in practice (from experience) it's probably good enough (also depends on how the storage is configured to scale). More important than quota enforcement is throttling (#22), probably.

So I think the user database becomes necessary if you want to change the quote system to something more immediate, or if you want to allow users to pick a domain name that's unrelated to their username. Another option for the latter is that they should set their domain name in wherever other people set their username. or maybe a username that starts with dns. is interpreted as one with a custom domain name. but that doesn't allow the RdfLayer to do a reverse-lookup and know is foo.com something we host or not.

So I think we need a user database when we want to support custom domain names, but not before that.