December 16th, 2018 11:20

Custom Blog Domains and where to attach them

meena Public Seen by 22

During the slow, slow development of this pull-request: add a custom_domain attribute for single-user blogs #340 several design questions have come up, and I think they would be easier to clear up here than with comments on specific diff lines in the PR.

The first question that came up from @baptistegelez is: "Should there be a Custom Domain: be a prompt on the User Creation screen?
It could be very confusing that this is your screen!

I think this can be reduced to even more basic questions…
The two issues that @baptistegelez linked:

to quote @baptistegelez from #94:

Some ideas of how this feature could be implemented, allowing to have single blogs bound to one domain:
- each user should have an optional custom_domain property.
- if this property is present, use it for all URLs related to this user.
- links like "Login" should redirect to the main domain, not the custom one.
- when visiting the user specific domain, only display their post, as if it was a single user blog.

After thinking more about it… it makes more sense to have the bind the custom_domain to an instance.
Heck, even a "single user" instance, could have multiple "author personalities"…

And this is just the design decisions…
On the technical side, i'm wondering if it will be necessary to have a URI (query?) builder step run before trying to assign routes to methods. Because all our routing code currently looks like:

#[get("/~/<blog>/new", rank = 1)]
pub fn new(blog: String, user: User, conn: DbConn, intl: I18n) -> Option<Ructe> {

and it's hard for me to tell what it should look after our transformation… especially since i don't know how it should be designed to begin with.


fdb-hiroshima December 16th, 2018 13:27

I feel more and more like multiple instances on one Plume will be tricky, and will add a lot of complexity for in the end a feature that will not be used by that much people. And for people who really want it there is a simple enough workaround. The use case in #94 can be covered by a front nginx redirecting to different Plume based on the server_name requested. I did not think about it earlier but it's actually the configuration I'm running with to test federation on my local machine.
Plume is not as heavy as mastodon, even on a low cost vps or a self-hosted raspberry pi multiple instances can still be run easily (I'm currently measuring less than 50 megs of ram, with SQLite, per instance). Then it would make sense to close #94 as wontfix and document the workaround I described, in favor of #241 which is far easier to implement.

Ana Gelez

Ana Gelez December 16th, 2018 15:09

Actually, I think I agree with you @fdbhiroshima, I'm not sure it is Plume's role to redirect on the correct page according to the domain name.


meena December 16th, 2018 15:27

it is not, but it is … kind of Plume's role to generate the correct URLs, or otherwise people have to fix up our generated URIs with Apache httpd's mod_proxy_html or nginx' http_sub_module.

but i think i now better understand that if we were to implement this, it should be bound to an instance, not an author.

Marek Lach

Marek Lach December 16th, 2018 15:39

I also think that to reddirect different blogs of a single user to different domains, a server-side configuration by the user, or simply a domain name redirect via nameservers will work just fine, since I also agree that it wouldn't really make sense to make Plume a truly single-user capable application.
Bigger blogs will surely have multiple authors. Maybe in the admin settings, or during installation, the instance admin could decide to hide the registration icon altogether from the front-end, if they wish, and the log-in icon also. This would give Plume the ability to feel like it can be single-user, without the need to do many technical changes.

What I think instead would help distinguish multiple blogs of a single user on an instance is the ability to upload custom blog headers?


fdb-hiroshima December 16th, 2018 15:44

Plume is generating relative urls for user content, and absolute urls based on the public domain given to plm at initialization for federation. I'm afraid I don't see your point there. Could you explain the issue?


meena December 16th, 2018 15:54

My understanding of the feature request is as follows — especially now after… understanding that a custom_domain should be bound to an instance:

That would need a little bit more of work than an nginx reverse proxy config, but def… a different type of work than the work i have been doing 😅


meena December 16th, 2018 15:58

We have a few issues open on the customisability: and would appreciate more input in that regard.

Marek Lach

Marek Lach December 16th, 2018 16:18

On public instances, like, it is not strictly necessary to have a configuration for per-user custom domains, because could be redirected to via a domain redirect with the domain register.

But it may very well be the case that a user wants to redirect their username to a custom domain, and direct their readers to that domain. If they have multiple blogs per user on a 'public' instance, it may help for the readers to visually distinguish those blogs, since they are like topics almost, even if they all belong to a single user. Hence why it may be a good to think about letting blogs have different colour-satuation-schemes applied to them in blog settings sometime in the future, just for the sake of public instances? This could be based on hex color codes, or something...


meena December 18th, 2018 14:34

okay, so, after thinking a lot about this, i'd like to summarize — in a table — which things make sense, and which might not make sense:

All our "instances" start out with a single domain (or a domain/port combination that uniquely identifies that). From there, we can then consider adding a custom_domain.

In this table, we'll try to explore these options, and what they look like as URLs.





Custom URLsame

Given that Plume's design so far is collaboration- and blog centric, instead of person/ego centric, we're effectively skipping the last option.

I believe that serving several instances from a single installation might make things tricky to actually secure, wrt database permissions and CSRF, etc…
If someone wants to run more than one Plume for different users & domains, they might be best off running multiple daemons on different ports, and with different DBs.