Only works if you don't room switch

[lukebarnard1]

I've so far optimised to have a good experience when staying on the same room. Room switching seems not to be possible...

[lukebarnard1]

Looking into this, a new sync is started when swapping rooms, with a filter to only receive events for the room being swapped to.

This should allow things like room name, topic, etc. to come down the sync but this doesn't happen in practice. Removing the indexdb sync data solves the issue. It's possible that we should be removing indexdb data when using a different sync filter, or alternatively not filter based on room ID.

[lukebarnard1]

One idea I had was to allow users to create new accounts for specifically using journal. That way, the /sync would be fairly quick, but this would become slower as the user starts reading more blogs.

Perhaps this requires a rethink of the general structure of journal itself. If multiple rooms syncing is too slow, maybe we shouldn't have multiple rooms in journal. The premise has so far been that one blog has several authors, each with >50 (by default) power and so each able to write a post. Readers join the room with the default power level of 0, being able to comment but not post (until in theory, an admin gives them the power level required). This model could fit a variety of existing sites, even if there is only ever one room.

An example of an existing site that could be put onto this model is http://dev.to, which is like http://medium.com for developers. Anyone can post an article if they have an account. In journal, the entirety of dev.to would exist inside a single room, called the dev.to room. It'd have an alias like #devto.

If dev.to were to swap to journal, they'd probably want their own journal server running at dev.to, so the alias would be baked into the journal instance with some hypothetical config.

They'd also want to keep their existing users, which could be done by creating a matrix user for each user. The interesting bit is the alternative - signing in to the new dev.to with an existing matrix account. The new login interface would give the options "Login, Register or Sign in with Matrix". If a dev.to user already has a matrix account, they could have a button in their settings to make the conversion, doing verification of the fact that they own the matrix account via a matrix room. The only issue with using an existing account is that the /sync would be slow (bringing in a lot of useless data for use by other matrix clients). So in fact it might be in their best interests to prevent users from using their existing matrix accounts somehow.

Anyway, this boils down to a single room, where new users create new matrix accounts and where everyone can create blog posts and comment etc. The /sync might not be that bad for the dev.to room, unless it's really really popular.

The counter example is http://medium.com itself, which allows blog creators to use DNS to point to their blogs. Users use one account across all blogs, which is how journal works currently.

To summarise the two solutions and their hypothetical/real equivalents are:

• 1 account per room
  • dev.to
• 1 account per blog site
  • journal (with aliases for individual blogs)
  • medium.com (with DNS for individual blogs)

[lukebarnard1]

This is much improved since the move to mrw.