Making bridges more accessible

As of now you need a full fat Synapse installation to be able to use bridges. This brings accessibility problems. Not everyone has the resources or time to invest into setting up bridges. It also creates a significant storage and resource burden on existing cheap VPSes. While you can run something like Matterbridge, it has limits that make it difficult to use for anything other than a few chats. Ideally you should be able to run a fully double-puppetted bridge as a normal user, so you can viably use other chat platforms.

There are a few ideas I have to this. I'm by no means an expert on Matrix and this probably should warrant discussion.

1. Have an optional, end-user exposable API that works like appservices. Perhaps you could be given a namespace as a user to run your bridge(s)

2. Introduce the concept of a bridgebox like Novachat. It would act as a amnesiac box for bringing in and pushing out messages, and would be accessed independent of the homeserver.

3. Allow non appserviced bots to create ghost users. I'd imagine them not having things like presence, sort of like how webhooks work on Discord. DMs would be a bit of a problem however.

All of these also have an unintended side effect of allowing bridges to be run in a way where the homeserver operator can't see your bridged communications with E2EE. This also should help with the performance problems seen commonly by large bridges (I'd venture to say that most bridges are pretty much unusable, minus ones from small untrustworthy homeservers). This would also allow normal people to run bridges on their home computers without exposing their IP address to the world. There's a lot of possibilities here.

There's also a lot of security things to consider. How would we make this safe for homeserver operators? How would we make it viable for homeserver owners to safely enable it for their users? What about performance?

No file, test, or entry point is identified. Start by comparing the three proposed approaches, then work through the stated security, performance, and homeserver-operator concerns; done would require an agreed protocol design and documented safety requirements.

Written by the indexing model from the issue text.