Brainstorm sensible defaults for a transition to a decentralized stack

[ellenhp]

I think the reason that Headway got a lot of traction on HN is because it currently, right now, solves a problem that people have. It provides maps for everyday use in a chosen metro area, without compromising privacy. If the project moves towards decentralized or federated hosting of an entire world map, I want to make absolutely certain that I'm personally happy with the level of privacy it provides (see: #50). But I also want to make sure that I'm not forgetting that a lot of people don't want to make requests to servers they don't control, at all, period, end of story. Headway must continue to be self-hostable. This issue exists to track that. The default should be for headway to bring up a self-hosted maps stack. We may choose to add a make planet target or some environment variables that control federation, but I don't want to lose track of what made people so excited about Headway in the first place.

Bottom line: Headway instances should never call out to external servers at runtime unless specifically configured to do so. Nor should they ever serve a page that solicits clients to call out to any external servers unless specifically configured to do so. At least, that's my opinion.

[ellenhp]

Closing, I don't think this is feasible.

[3nprob]

Closing, I don't think this is feasible.

How come? All of this sounds like a great vision IMO - I can see no fundamental reason why this should be intractable. Mesh-like federation may be a lofty goal and far away but why not build with this vision in mind? A lot of what you're mentioning just comes down to sane defaults, clear communication around expectations, and easy configuration. It doesn't necessarily need to imply more complexity - rather I'd argue that a "self-hosted first" mindset especially benefits all the engineers touching the code or stack as it strives for clarity and simplicity.

I see this a lot.
For one example, compare SimpleLogin and Firefox Relay. Both:

• Solve the same problem, have similar features
• Are developed in the open
• Available under a FLOSS license
• Have an explicit subgoal from project maintainers to be possible to self-host
• Have a hosted deployment driving a revenue to the main developers (in the case of SL, all or most)
• Have around 4.5k commits to date

I'd say where they most significantly differ is on this question.

Coincidentally, SimpleLogin is super straightforward both to set up and start coding on. Things that are not obvious get addressed continuously as external people address them. You can realistically both start contributing and set up your own instance in less than a day if you know what you're doing.

Firefox Relay is... A byzantine mess. There's a Wonderland of institutional implied knowledge. Things are out of date all over the place. Even a sophisticated engineer will realistically need several focused days spent digging into multiple repos to set up a simple deployment. Realistically most people who code on this will have people internally at Mozilla to talk to when they get confused. I don't think anyone at Mozilla is necessarily happy with the situation or that the SimpleLogin devs are just "better".

I think this seemingly minor difference in mindset makes the whole difference. In the end you may even be saving time by not taking shortcuts at every other corner that builds into technical debt that no one else will ever address unless you make the call for it.

[ellenhp]

Just to close the loop here, we talked a bit about this in the headway matrix room.

To avoid doubt, Headway is and will remain self-hosted-first. Centralization is an explicit non-goal. I'm just closing this issue because I think it's not the biggest priority right now to have multiple instances cooperate.

We also discussed a bit that even though networking instances might not make sense for things like serving basemap tiles, federation might still make a lot of sense for some aspects of the stack. For example, a canonical instance could exist and call out to other local instances for things like transit routing. This is ideal because curation of transit feeds requires local knowledge. I could run a canonical global instance for Headway, but I don't know which transit agencies in e.g. Helsinki are the most important, and I don't know how to approach them to potentially get an API key for GTFS-RT feeds. That's just not something I can do without local knowledge and local presence.

Federation for transit routing would mean that, as a Headway user, I would be able to continue using the canonical instance if I wished to do so, and adding transit support to my own city is something that I could do without even needing to go through the maintainer of that instance.