Relay's locality model: seen where it was made El modelo de localidad de Relay: visto donde se hizo
IssueNúmero 04
How a post reaches only the people near where it was written, what the phone tells the server, and what it never does. A design, partly built. Cómo una publicación llega solo a la gente cercana al lugar donde se escribió, qué le cuenta el móvil al servidor y qué no hace nunca. Un diseño, en parte construido.
Este texto todavía solo está en inglés.
1One rule, two directions
Relay 2.0 is a location-based micro social network. The rule fits in a sentence, and it points both ways. You only see posts created within about 10 km of where you are now. Your posts are only visible to people currently within about 10 km of where you posted.
That is all the model needs. Everything in this article is how to make it true without turning the server into a map of where everyone has been.
2Per post, not per account
Locality attaches to the post. There is no "home city" on your profile. Post from one city today and another next week, and each post reaches the people near where it was made. Someone travelling reads the place they are in, and their old neighbourhood keeps what they left there.
It also means a post is tied to a physical moment. You cannot post "from" a neighbourhood you are not in, because the phone supplies the location at the time of writing. We call that honest rather than secure: someone determined can spoof a phone. The goal is that ordinary use cannot lie by accident.
3What the phone sends
The client does not send your coordinates. It snaps the GPS reading to a coarse geohash cell at precision 6, about 1.2 by 0.6 km.1 A post therefore says "the neighbourhood", not "the street address". The server never receives anything sharper, so it cannot leak anything sharper.
Location is opt-in per post. If you attach no cell, the post is private to the node and appears in no locality feed. It is a different kind of post, not an error.
4What the viewer sends
To read, your phone sends where you are as a query parameter on that request. It is a per-request parameter. It is never stored and never logged. The server uses it to answer and forgets it. We say this as a design rule and we want it reviewed, because it is the claim that matters most.
5How the server answers
No spatial database is needed. The server works out a bounding box around the viewer, filters posts whose cell falls in it, and then checks the exact distance with the haversine formula. That keeps the whole thing in SQLite, which is the default, or in Postgres without PostGIS. The radius is a per-node setting, LOCALITY_RADIUS_KM, with a default of 10.
the idea in Pythonbox = bounding_box(viewer, radius_km)
near = [p for p in posts_in(box) if haversine(viewer, p.cell_center) <= radius_km]
That snippet is a sketch of the approach, not code from the repository.
6Open membership
Joining is separate from seeing. Anyone can join a node from anywhere: location shapes visibility, not membership. A node can be set with ACCESS_MODE=open or ACCESS_MODE=invite_only, and invite-only stays for closed circles.
7Why bother
Local community has eroded, and there is no low-friction digital commons to replace it. A rule this blunt gives a street its own channel without asking anyone to follow anyone. It also makes a good constraint: a post that cannot travel cannot go viral, so there is nothing to optimise for.
8What is built, what is not
Specified: the feed rules, the cell precision, the per-request viewer location, open and invite-only membership. In progress: the Python backend that will implement the query. Not built: the shipped app. The privacy claims above are design intent and need an outside review before anyone should rely on them.
Relay has no licence file yet, so we do not call it open source. The repository is at github.com/nemoNoboru/relay. Issues about the idea can go to this site's repository.