dedicated aether server

General
#1

Hello!

I’m putting it in general, as it’s more or less a discussion starter and not a feature request.

I’ve been looking at a lot of alternative social media solutions, and it may be one of the better ones. Down to the idea. At first, I was thinking of running a mastodon/similar instance on a small, personal server (currently raspberry pie) to replicate what social media does, but it’s not coming together. Then I found this, and I’m thinking that it may be a prime candidate if it can run as a dedicated server, that the user’s devices connect to.

That could help to develop an android app as well, as your “account” is now not tied to the devices that you access it on, and you could do some kind of device discovery, or just use an open port. (you could get a reliable address anywhere if normal port forwarding is not an option with a combination of a VPN and DDNS)

It also has another caveat: People can monetize by providing this service from their computers. That is still like half of what Facebook/Twitter does, but at least we get to the point where they can not act as all around monopolies anymore and need to actually please people. It may actually be better than email in terms of mobility, as you can’t lose more than half a year of messages, and you can download/upload your keys to transfer your identity.

#2

Apologies, since it’s the first time you’re commenting here, your comments got flagged. I just resolved the flags so they should now be visible publicly.

For the idea, you’ve pretty much hit the nail on the head and this is something that we’re working on. In fact, I do have a dedicated server running as a test myself.

Right now those dedicated servers are not acting as backends to any mobile devices, they act as headless backends to help the network. However, the plan is so that we want to have the ability to run a backend on, say, a Raspberry Pi you have at home, and your mobile device connects to it, using it as a 24/7 available server. This removes the need for the mobile device itself to stay online for the network to work, so it makes the mobile devices possible.

We haven’t thought about monetisation on a per-user basis because ultimately when you run such a service, you are also providing service to yourself, not only to other people. So it’s doing a double duty in that — you are getting paid in the sense that it gives you access to the network. If we end up with a need to incentivise people to put up dedicated headless servers like this up to help the network we can think of some sort of payment infrastructure for this, but for the time being we don’t seem to need it.

#3

No probs on the flags :slight_smile:

I am trying to run a backend on a pie actually. It does not just make mobile possible, but also makes it possible to securely share identities between multiple devices, and may also allow 1 household to use 1 node if it can support multiple users.

That could actually also be a side feature for messaging, as we can rely on the address of the device for sending messages to a user, or even “private” rooms. Private as in it can theoretically have a master node, and only nodes that were given access can read it. Not leaking from such room, is up to the trust between the users (I trust you not to put this room into the public data pool).

Yeah, 2 ways of monetization I could think of is:

  • special client, and show ads to the user (If you do not want ads, host your own)
  • some form of “checkmark” service, that just says that “we know who exactly this user is”, and that user pays in some way. (ads or a subscription). That feature has value, but must be federated. It also means that if you do not like one of these you can say “I do not trust that provision”, meaning that those companies need to keep a good image.

Both of these are auxiliary and do not require changes to the protocol itself. We can also count in “affiliate marketing”, but that is completely independent from any system we’d provide.

#4

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/