What's the support for plugins?

[souperk]

I was thinking that social media platforms could support any app that connects people together.

For context, some examples could be job searching, dating apps, and ride sharing.

Those extensions or plugins of the social media platforms, could define a higher level protocol specific to the domain they providing a solution for. In order to do that, the at protocol would need to support some components that would make it possible:

1. create messages that are published through the social media platform (include a plugin id on the message metadata)
2. connect to aggregator services specific to the plugin
3. support for user authenticated information sharing

Of course there are other changes that are specific to the platform like custom message rendering, but I think the scope of this repository is limited to the protocol.

How would this look like with the at-protocol? Is there any research you can share? Is there a roadmap? Is this within your scope at all?

[dholms]

Yup yup we totally have this in mine! It's actually the purpose of Lexicon.

Atproto will allow application developers to define & publish schemas related to their domain.

We'll be deploying a generic aggregator that outputs a filterable firehose of all the data in the network. Devs that create a lexicon would need to create a client for the app as well as a view server that intakes that firehose & outputs views of data relevant to their app.

Still a bit of work to do on user authorization. But we will soon have a flexible scheme that allows data to be remixed & extended between applications

[pfrazee]

Adding to @dholms answer, new applications/usecases in atproto depend on 3 things:

1. The data and API schemas (Lexicon)
2. Services which aggregate the data and/or provide business logic for it (eg feed algorithms or forum hosts)
3. Clients which can render UIs related to them

Data & API schemas

As Daniel mentioned, Lexicon is the schema definition language for AT Proto. You use it to declare HTTP GET methods, HTTP POST methods, data records, and general object shapes. We have tools (which we'll package for everyone soon) that generates typescript code from the lexicons, giving you static type validation as well as runtime validation for clients and servers.

Lexicon has some features specifically designed for custom applications & overall extensibility. Schemas are defined using reverse DNS (eg app.bsky.feed.post) so to create new schemas you register a domain and identify your schemas off of them. There are also extension-points in existing schemas; for instance the Post schema has an embed field which has some well-known value types but which can potentially use new value-types.

Services

Data published in AT Protocol gets aggregated in the same way that websites get crawled by search engines. This is a good foundation for a lot of open content on the social graph -- you create services that host this aggregated data, with its own opinions potentially placed on top. Think search, feed algorithms, job listings, event listings, etc.

We're also looking at ways for users to send authenticated requests to various services. This model matches more closely with forums, storefronts, admin panels, etc.

In both cases, the services will be hosting JSON over HTTP using their Lexicon specs.

Client UIs

This is the more difficult area. There are three approaches we can take to this: separate apps, UI plugins, and UI lexicons.

Separate apps are the most straight-forward: if you want to build a forum on AT Proto you build a forum app. This works but it suffers from poor integration with other apps; you can't introduce new features into an app you didn't build.

UI plugins are the most flexible but difficult to execute upon. This would likely be wasm or javascript that an existing app chooses to run. It could be an html app run inside of a webview. The challenge with UI plugins is you need to think carefully about security and performance while also giving these plugins enough power to do their jobs well. It's not an impossible direction to take but it makes me nervous.

UI lexicons have a lot of potential but they're also difficult to execute. This would be lexicons which are acting like a UI language similar to HTML. Rather than adding a scripting language like HTML did, the UI lexicons would stay strictly declarative and aim to introduce enough behaviors to describe interactions with a service and the surrounding client data. If this can work it would solve security and performance and make the friction to extending a client very low, which is exciting. The challenge is creating lexicons which have enough sophistication to do the job.