Yes — having one backend per household, with the user keys stored on the individual frontends (devices) is something we are planning for. In fact, the general goal in that context is to have the public spaces like parks and coffee shops to be able to host their backends, and when you go somewhere like this, you would be able to connect the resident backend in that location offered as a service. Very much like how SMTP and IMAP works, or at least, the way they used to work in 1980s in an academic setting.
This might be something of a stretch, we’ll see. Perhaps most people will prefer to have their own backends instead of using someone else’s, because they have no guarantees of whether a third party backend will actually successfully deliver their content to the network, or will even want to.
The issue here is another feature we are thinking about. We want the users to be able to choose which communities are shared on their backend. So that means a backend would have a ‘profile’ on its own, that is separate from the profile of the user, which controls that. This is the weird bit, because as of now our backends are largely completely identical in behaviour and the user-specific bits are in the frontend.
On the other hand, having a backend be a standalone entity, combined with the idea that a backend should be able to choose what communities it propagates, does raise some questions such as:
- Who is the ‘admin’ for that backend?
- Who gets to choose whose communities get shared on that backend? Does that backend do a union set of all communities its frontends subscribe to or share?
- What happens if you connect to a backend and post to a community that backend does not want to share?
- How would a frontend would even know that backend is unwilling to share?
- What happens if that backend is malicious and acting as a honeypot?
There are things a frontend can’t conclusively know about a backend, if that backend is hosted by someone else. For example, a frontend cannot discern the absence of new posts on a community from a backend refusing to receive or propagate the content of that backend.
So in the case a backend is untrusted and a frontend is connecting to it, there are some issues we need to work out to make the security boundary as obvious as humanly possible. These obviously don’t apply to trusted environments where you’re running the backend yourself, but they do apply in the case of a family sharing a backend, or a backend situated on a cafe.
For using specific backends as private rooms, it’s probably better to have them act as perfect a copy of the network as possible — generally speaking when you connect to someone else’s backend that you can’t trust, you want to minimise your interface with that backend. So private rooms is technically possible, but in practice, it leaves that frontend at mercy of that backend re: actually delivering content.
For monetisation, our plan is to not monetise the P2P as much as possible and focus on the Pro / hosted bits of the app sold for business use cases — that does make things simpler. We do in fact have a checkmark service and we offered it in the past to Patreon subscribers. It worked well, but the issue has been that I had to manually give checkmarks to everybody and that proved to be unscalable.
We’ve just announced our plans for the addition of private communities to Aether, so at least that feature is coming now: https://aether.app/blog/2021-02-08-new-day-new-folks-new-beginnings/