Introduction
As we start developing a database for the movement map, I'm increasingly excited about the potential and I have some ideas for setting it up to be resilient and useful long-term.
Fundamentally, there's a limit to how deep and accurate our data entry can be as outsiders filling in a database, and as the database grows, it will get increasingly difficult to keep updated. Having all the data on a single server is also inherently fragile. In the course of researching for the movement map, one of the best analogs I found was delisted and gone forever.
The long-term solution is to get organizations to be able to claim and maintain their own listing, and host the information in many places besides our server. This allows listings to have both deeper and more current information, and be resilient to any changes that happen on our end.
ATProto is a framework for decentralized data storage and social networking, and can future-proof the work that we are doing now.
My proposal keeps the initial project largely the same - it's essential we stay focused on the immediate needs of organizers and don't start trying to build a social media network. Flexibility is a core part of ATProto, and all we need to do now is keep the door open for integration down the line.
How it works
The database is organized in such a way that the relevant details for a public-facing profile of an organization could be exported to JSON.
These details are able to be arranged into a profile - something like:
We'd likely already be doing something like this, but the critical piece is that this public data can be separated from sensitive data and that it can be exported to JSON, which is the format for ATProto records.
The next big piece is that organizations can sign in to our server using ATProto (which works with Oauth, like 'sign in with google' buttons) and be granted permission to edit only their listing. This adds their unique ATProto DID to their listing.
At this point, the orgs have the opportunity to enter more information and fill out their profile.
And ta-daaa, we have a lovely public-facing profile with deep and accurate information:
The last step is to push this information to the organization's Personal Data Server (PDS), which is storage space on the ATprotocol that is uniquely linked to them.
The whole system would look something like this:
The only data leaving our server would be the info for profiles of vetted organizations which have signed in with an ATProtocol account. Many listings would still exist that are not claimed by organizations or on protocol.
Basically all that has changed is:
Login and permissioning to our server using ATProtocol
Exporting data as JSON to their PDS
Disclaimer
I want to reiterate that the focus should remain on building for organizers. Meeting the needs already expressed and filling out the database as planned are the only way that we will have the reach and clout to make it worth it for orgs to sign up and tend their own listing.
I don't think these features should be too hard to implement, but if they conflict with anything the minimum future-proofing would be structuring the database in a way that it can easily export a JSON of public-facing info.
Also. All data on ATProtocol is completely public. It's just how the protocol works, and is not meant for sensitive data. We need to be very mindful about not getting things mixed up.
Hype
ATProto is really cool. It's open source, easy to build on, and has a lot of momentum right now as a legitimate alternative to the corporate-owned internet.
You may already know Bluesky. It's the flagship app built in the ATmosphere. It's cool and most people have heard of it, but it's only the tip of the iceberg.
Here's where we're going:
Imagine something like this for organizations -
Being able to express needs and services: An org doing a mobilization can indicate that it needs banners and a makerspace nearby gets notified.
Campaigns can be created by a coalition and updated across all the members' profiles.
Badges can indicate an org is going to a mobilization or part of a coalition and link directly to more info about those things
Shared purpose affiliations - orgs can easily see who else is working on what they are in their area, and strategize with them
Classes and events listed right on an org's profile
The best part? Lanyards is open source. As are most things on the AT Protocol. That means that we can take the work already done there and build on it however we want.
It's a relatively small space but growing quickly, and the community is very active. We would get a lot of exposure if we were building something good, and receive a lot of community support.
The structure encourages collaboration. Developers can work together to create complimentary and compatible apps, for example:
(btw - this proposal is written in Leaflet and published on the atmosphere!)
Conclusion
We should keep an eye on this horizon as we develop the tools that organizers need right now. We have a need defined and meeting it is the best guideline for developing in the right direction. As we build, let's keep doors open that will enable us to make the most of the work we're doing.