What is the movement map?
The movement map is a project currently in development to create a database/directory of progressive organizations.
We're looking at hiring Ecomap.tech to design the database architecture, provide hosting, and create the organizer interface.
Our first use case is a toolset for organizers to log their networks, discover new partners, and analyze coalitions. They will likely be filling out the database primarily based around their geographic location and existing networks.
As it grows, we want it to become more comprehensive and public facing, to help people find and index values-aligned organizations near them.
I believe that integrating with the AT protocol early on will set us up for a more sustainable and comprehensive project in the long run.
What is the AT protocol?
It is a set of open standards for decentralized publishing.
Basically, everyone has an AT account and an online hard drive with files in it, which are defined by a set of rules called a lexicon.
Platforms such as Bluesky or Leaflet are designed to read and write in a certain lexicon. For Bluesky, the lexicon defines a 300 character post that shows likes and comments, for Leaflet it's a document with headings, body text, and background color.
How is ATproto helpful here?
In this case, we would define a lexicon for an organization's attributes. For example:
Logo
Name
Mission
Size
Location
Within the lexicon, we can make certain items required or optional, set parameters for accepted inputs such as character count, or specify formats such as image or address.
When someone adds an org through our system, it will create a record in their drive, identified by the lexicon we defined.
Now we can find that record and display it in a template with the information filled in:
Of course, this is just one view of the data. It could just as easily be indexed, sorted, and visualized however we want alongside all the other records following our lexicon.
How is that different from a regular database?
With a regular database, all moderation power is centralized to a small team and the whole thing can be lost or degrade if they are unable to keep hosting or maintaining it.
With the AT protocol, these records are stored with whoever created them. Even if our service goes down, someone could easily build another one around the lexicon we defined, and all the files would still be there, spread around the ATmosphere.
Ours actually doesn't even have to go down! People can and do build multiple platforms around the same lexicon, allowing others to make projects that can add to and access all the data stored in that lexicon format.
We still get a central server
Now, just because anyone can make a record doesn't mean that we want every single one that matches our lexicon. And having all those files scattered around doesn't make them immediately easy to access.
What ATproto does is send our server a notification every time a new record with our lexicon is created. Then on the server we can integrate those records to our database however we want. Maybe they get added automatically, or wait for approval, or we can even block a particular contributor. We can moderate our platform without having to be the single source of truth, and make the data open to everyone while managing permissions to our instance however we want.
ATproto account integration
One way that ATproto could save us some work is by having users sign in with a Bluesky account, like "sign in with google". This feels a bit easier to get people onboard than "create an Ecomap account", and also one less feature we have to build/host from scratch.
People would have to sign in to add orgs through the system. The whole point of ATproto is building social networks, so permissioning features should be easy to build around these accounts.
An added benefit to this is introducing people to the ATproto network. I think it's a really cool community and as organizers we should be using collaborative open source software whenever possible.
Conclusion
Building an ATproto layer to the movement map would let us:
Decentralize the database, giving it reach and resilience beyond our project.
Accept and encourage public contribution while maintaining our curated instance of the database.
Facilitate log-in and permissions through ATproto accounts.
Enable gradual adoption of social features as we shift towards new use cases and try to build a comprehensive database.
I really think this would be setting us up for a healthier project long term, and take some of the load off our backs. We don't have to be flawless sole stewards of the database, and other people would be able to make tools and features independent of us. It opens the door for collaboration in a way that it wouldn't be if all the data was solely on our server.
Next steps
All this said, I think Ecomap's role, and the architecture overall, doesn't change that much. We need their help developing an architecture that will be flexible to future needs, hosting and managing the server with our database, and creating the toolset for strategic organizers on their platform.
Hopefully they're also willing to develop the ATproto part. From what I understand, it's a relatively easy standard to work with, and the biggest thing would be figuring out how to make the lexicon and database work well together and be open to future additions.
I think to start we should at least have sign in and permissioning through ATproto, and keep ATproto features unobtrusive but well implemented.
Bonus points:
We are likely to get high visibility through ATproto network, and there's a lot of community support around new projects built on it.
Values-aligned tech. Building on open source, inherently collaborative software feels right for a project like this.
Concerns:
I'm not sure how Ecomap will be able to or comfortable working on something new and partially outside of their platform.
It will be more work to develop another layer to our system.
I'm not sure how complex the lexicons can be; or how they would be able to interact with multi-layered databases.
The 'one lexicon, one post' format I described here is a simplification. Often a post will be an combination of a couple types of records. For example, likes on a Bluesky each a unique record under a simple 'like' lexicon.
This could let us do more complicated stuff later on, but out of the gate we should keep it as simple as possible and minimize how much AT-specific stuff Ecomap has to do upfront.
There will be some unique things we have to figure out with this setup. For example:
How to update existing listings. If the org is hosted on the original poster's PDS, I don't think other people can edit it. May mean with each update the whole listing is "re-posted" on the updater's account, and our database only accesses the most recent version.
ATproto records are totally public. If someone lists a ton of orgs near them, a bad actor may be able to approximate their region/location. I guess people tag their location and affiliations on Instagram all the time, so maybe not the biggest concern.
ATproto is relatively new; its longetevity or success is not proven. However, Bluesky alone has 36 million users and not likely to disappear overnight. I think building in a network like this provides far more resilience than a single server.
Thanks for reading!
I hope this was reasonably easy to follow. I'm excited about this platform and I think building this from the start will make it easier to grow organically and implement features as we go.