Preliminary Types Support #1

Open
opened 10 months ago by deadsuperhero · 5 comments
Owner

It's evident that I need to come up with a couple of generic methods for fetching the JSON from a given activity object. Part of the issue here is that fediverse platforms all use different APIs for object retrieval. Given that we're currently doing this on the client side via an API, and not in conjunction with a singular backend that federates, it might make sense to break this up by type and by platform.

The types we need to support are:

  • Note
  • Image?
  • Video
  • Article
  • Event
  • Review
It's evident that I need to come up with a couple of generic methods for fetching the JSON from a given activity object. Part of the issue here is that fediverse platforms all use different APIs for object retrieval. Given that we're currently doing this on the client side via an API, and not in conjunction with a singular backend that federates, it might make sense to break this up by type and by platform. The types we need to support are: * Note * Image? * Video * Article * Event * Review
Poster
Owner

Support for video could be done by using PeerTube: https://docs.joinpeertube.org/api-rest-reference.html#operation/getVideo

Support for video could be done by using PeerTube: https://docs.joinpeertube.org/api-rest-reference.html#operation/getVideo
Poster
Owner

Some thoughts about type detection: no one platform really seems to support all types yet. To detect the type, we have to look up the JSON body...but, in order to do that, we have to basically do a lookup through a platform's own API endpoints.

There isn't a way to automatically get this JSON straight from the HTML page, sadly. That's just not how it works.

So, the process might look like:

  1. User puts a link into the tool.
  2. The tool checks the generic nodeinfo endpoint to determine what kind of software it is.
  3. The backend reconstructs the API endpoint for the type in question
  4. The post body is fetched via an API request, deriving the post ID from the original link that was used.
  5. The tool determines the post type, then conditionally selects a type component to render it all.
Some thoughts about type detection: no one platform really seems to support all types yet. To detect the type, we have to look up the JSON body...but, in order to do that, we have to basically do a lookup through a platform's own API endpoints. There isn't a way to automatically get this JSON straight from the HTML page, sadly. That's just not how it works. So, the process might look like: 1. User puts a link into the tool. 2. The tool checks the generic nodeinfo endpoint to determine what kind of software it is. 3. The backend reconstructs the API endpoint for the type in question 4. The post body is fetched via an API request, deriving the post ID from the original link that was used. 5. The tool determines the post type, then conditionally selects a type component to render it all.

The purpose is to serve as a handy reference for developers building protocol implementations to see how to render different activity types on their frontends.

Does this refer to the ActivityPub protocol, i.e. JSON-LD formats, and vocabulary extensions that are used over the wire by various apps?

The Peertube API is a good example, as the JSON seems to very API- / app-specific, just like Mastodon's API's. But I can be mistaken. I think a general issue on the fedi is that many apps just define their own extensions and how they did that can only be found by reverse-engineering from their codebase.

I created fedi.foundation draft site, as a possible future place where true vocab extensions are well-documented (think design patterns in pattern library), so that any app that works in the same domain can interop if they comply to that.

A universal tool to demonstrate UI's should ideally be based on those (emerging) standard vocabs. I have the idea - and when I find time - to investigate the "AP used in the Wild" to track all the stuff that is currently used.

Imho not doing such efforts means we'll end up in the Spaghettiverse and it becomes ever more complex to join the fedi with a well-integrated app. Future direction where I'd love to see fedi go is what I just wrote down in this toot. That vision would map greatly onto this project as well.

> The purpose is to serve as a handy reference for developers building protocol implementations to see how to render different activity types on their frontends. Does this refer to the ActivityPub protocol, i.e. JSON-LD formats, and vocabulary extensions that are used over the wire by various apps? The Peertube API is a good example, as the JSON seems to very API- / app-specific, just like Mastodon's API's. But I can be mistaken. I think a general issue on the fedi is that many apps just define their own extensions and how they did that can only be found by reverse-engineering from their codebase. I created [fedi.foundation](https://fediverse.codeberg.page) draft site, as a possible future place where true vocab extensions are well-documented (think design patterns in pattern library), so that any app that works in the same domain can interop if they comply to that. A universal tool to demonstrate UI's should ideally be based on those (emerging) standard vocabs. I have the idea - and when I find time - to investigate the "AP used in the Wild" to track all the stuff that is currently used. Imho not doing such efforts means we'll end up in the Spaghettiverse and it becomes ever more complex to join the fedi with a well-integrated app. Future direction where I'd love to see fedi go is what I just wrote down [in this toot](https://mastodon.social/@humanetech/107359117117615571). That vision would map greatly onto this project as well.
Poster
Owner

Hey @circlebuilder, totally appreciate you being here and sharing your thoughts!

Does this refer to the ActivityPub protocol, i.e. JSON-LD formats, and vocabulary extensions that are used over the wire by various apps?

So, I've been thinking about this. Initially, I was planning on sort of doing an approach through a platform's given APIs:

My original idea

ap_typerender is a simple client-side application with no backend, and simply exists to render data from ActivityPub objects into simple templates that developers can customize. It could be used to understand how to render those objects in more complex applications.

  1. User posts link in form
  2. Tool does a check against nodeinfo on the domain to see what software it is, does a rough guess as to what types that software supports.
  3. Makes a corresponding API call to get the activity JSON
  4. Renders that JSON in a predefined template.

However, your comments have raised an interesting thought on perhaps a better approach:

Proposed Revision

A universal tool to demonstrate UI's should ideally be based on those (emerging) standard vocabs. I have the idea - and when I find time - to investigate the "AP used in the Wild" to track all the stuff that is currently used.

So, this resonated with me a bit, and made me think: maybe my approach to the tool is actually backwards. What if ap_typerender instead interaced with a very simple backend that contained full ActivityPub types? Instead of just trying to scrape data off of an application's API, it instead performs a simple WebFinger request to receive a federated copy of a public post?

  1. User posts link in form.
  2. ap_typerender interfaces with a backend, maybe GoFed GoToSocial, to send a WebFinger request for a copy of that post that can be seen locally. (Edit: the post is not stored. The tool is just meant to demonstrate what an activity can look like)
  3. The Activity JSON from the federated payload gets pulled in, along with very basic metadata concerning the origin (ex: domain, platform, platform_icon)
  4. The project ships with templates for each type, which developers can play around with to see how the Activity looks.
  5. The matching activityType for the Activity being previewed is rendered on the page: if you change the template to use different fields or different styles, the preview changes.

The second idea is probably "more correct", but it is also something that I have not coded before. Previously, I was experimenting with making a custom Pleroma frontend called Sporadic, which kind of is a variaton on the first method (use a platform's APIs to render that platform's data in an interface), but the second method probably makes a lot more sense for platform-agnostic federated data.

Would love to hear some further thoughts on this!

Hey @circlebuilder, totally appreciate you being here and sharing your thoughts! > Does this refer to the ActivityPub protocol, i.e. JSON-LD formats, and vocabulary extensions that are used over the wire by various apps? So, I've been thinking about this. Initially, I was planning on sort of doing an approach through a platform's given APIs: ### My original idea `ap_typerender` is a simple client-side application with no backend, and simply exists to render data from ActivityPub objects into simple templates that developers can customize. It could be used to understand how to render those objects in more complex applications. 1. User posts link in form 2. Tool does a check against nodeinfo on the domain to see what software it is, does a rough guess as to what types that software supports. 3. Makes a corresponding API call to get the activity JSON 4. Renders that JSON in a predefined template. However, your comments have raised an interesting thought on perhaps a better approach: ### Proposed Revision > A universal tool to demonstrate UI's should ideally be based on those (emerging) standard vocabs. I have the idea - and when I find time - to investigate the "AP used in the Wild" to track all the stuff that is currently used. So, this resonated with me a bit, and made me think: maybe my approach to the tool is actually backwards. What if `ap_typerender` instead interaced with a very simple backend that contained full ActivityPub types? Instead of just trying to scrape data off of an application's API, it instead performs a simple WebFinger request to receive a federated copy of a public post? 1. User posts link in form. 2. `ap_typerender` interfaces with a backend, maybe ~~GoFed~~ GoToSocial, to send a WebFinger request for a copy of that post that can be seen locally. (Edit: the post is not stored. The tool is just meant to demonstrate what an activity can look like) 3. The Activity JSON from the federated payload gets pulled in, along with very basic metadata concerning the origin (ex: domain, platform, platform_icon) 4. The project ships with templates for each type, which developers can play around with to see how the Activity looks. 5. The matching activityType for the Activity being previewed is rendered on the page: if you change the template to use different fields or different styles, the preview changes. The second idea is probably "more correct", but it is also something that I have not coded before. Previously, I was experimenting with making a custom Pleroma frontend called [Sporadic](https://codeberg.org/deadsuperhero/sporadic), which kind of is a variaton on the first method (use a platform's APIs to render that platform's data in an interface), but the second method probably makes a lot more sense for platform-agnostic federated data. Would love to hear some further thoughts on this!

I really like the idea. What this makes me think about on the UI end is a tailored, hosted version of StoryBook (need not be Storybook, but its just and example for conveying the idea of having an online styleguid, a pattern library of UI components), and - if storybook doesn't have this already - combined with an online code snippet editor.

On 1) and 2). It may be hard to know what URL's to post. Maybe on 1) someone curates previously posted URL's that worked turning them in an URL pattern to look out for and/or adds some explainer on how to obtain them. And on 2) maybe not the specific message (with someone's personal text in it) is stored, but the format of that message with dummy Lorem Ipsum content.

So that over time a directory with collections build up that constitute "what's out in the wild". A collection for each individual app with clear names of the different patterns e.g. "Mastodon: Regular post", "Mastodon: Post with Content Warning", "Pleroma: Post with Content Warning" etc. In terms of navigation you could either choose an App and see all UI components, or you choose one componant and the switch between apps to see differently supported variations.

Such design would also encourage people to create UX prototypes that aren't coded yet, and other people to give feedback on them or adjust style sheets à la CSS Zen Garden.

Bit all over the place, my thoughts, but you get the idea 😅

I really like the idea. What this makes me think about on the UI end is a tailored, hosted version of [StoryBook](https://storybook.js.org/) (need not be Storybook, but its just and example for conveying the idea of having an online styleguid, a pattern library of UI components), and - if storybook doesn't have this already - combined with an online code snippet editor. On 1) and 2). It may be hard to know what URL's to post. Maybe on 1) someone curates previously posted URL's that worked turning them in an URL pattern to look out for and/or adds some explainer on how to obtain them. And on 2) maybe not the specific message (with someone's personal text in it) is stored, but the _format_ of that message with dummy Lorem Ipsum content. So that over time a directory with collections build up that constitute "what's out in the wild". A collection for each individual app with clear names of the different patterns e.g. "Mastodon: Regular post", "Mastodon: Post with Content Warning", "Pleroma: Post with Content Warning" etc. In terms of navigation you could either choose an App and see all UI components, or you choose one componant and the switch between apps to see differently supported variations. Such design would also encourage people to create UX prototypes that aren't coded yet, and other people to give feedback on them or adjust style sheets à la CSS Zen Garden. Bit all over the place, my thoughts, but you get the idea 😅
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: postmodern/ap_typerender#1
Loading…
There is no content yet.