Basic Metadata for Modality Spaces

Working Groups WG Community Standards
1

Cross-posting opensocial.group spec thoughts / questions I added to a Tangled issue:

Unfortunately Tangled doesn’t let me subscribe to the repo and get email notifications so it seems worth posting over here too.

Me @lou.gg and @erlend.sh were discussing interoperability between different apps around the idea of “threads” in the context of things like forum threads and chat threads. The thought right now is that forum threads and chat threads are clearly different modalities that might want different handling, so they should have their own lexicons. Still, I do think there’s value in having all of these threads be able to describe themselves in a somewhat universal way. Almost like OG metadata for permissioned spaces.

There are a few different sides of this that I think might be useful to have standardized in opensocial.group and wanted to get feedback.

Standardized Metadata Records for Spaces

My thought is that we can create something like a group.opensocial.space.meta/self record in every space that has some minimal metadata that can be used to inform other apps what the space is about even if it can’t directly interact with the modality because it isn’t supported. For example some basics like title, description, image / avatar, or feature image would allow us to make something like a link preview for a space in any app regardless of modality.

The current proposal already has records in the members/self space that has a title and description for a space, but I think that it’d probably be best if there was metadata in the space, so that any space that you get an at:// URI and a credential to can also be described just by looking at its meta record.

Announcing a Space Publicly

Another use-case that we had was the ability to index threads across the atmosphere. We already have a declaration record in this spec for announcing the existence of a group on the firehose, and I think it could be useful to have a standard for doing the same thing for spaces.

This would make it possible, for example, to have an AppView that indexes all of the public forum topics created across any group, possibly filtering based on the space’s modality.

I’m imagining that a space declaration record would contain simply the space’s at:// URI, and AppViews could ignore that contain URIs with space types that they are not interested in.

Providing a Default App for Space Links?

This is a little more uncertain, but it occurs to me that it would be useful to be able to, for example, post something that resolves to an at:// link to an AtmoBB forum topic in a Roomy chat message, and have Roomy be able to display an inline link to the forum topic with the title automatically fetched from the metadata record.

I’m imagining, at the underlying data level, when that chat message gets stored on protocol, it would be best if that link could come with an at:// URI to the space that is being linked to. That would allow, for example, certain apps that support the AtmoBB lexicon to open the forum topic without leaving the app, instead of it being just a link to the AtmoBB app.

But if the app doesn’t support AtmoBB’s lexicon, then it would like to link to some app that can display the forum topic properly. Maybe it would make sense for the space metadata record to also contain a link that can be used to view the thread in the app that created it? That way, given just an at:// URI to a space, any app can display the basic information for the space, and know which link to send the user to if they would like to view it in its native app.

Note: how to get the at:// URI when a user pastes in a link to a specific app is a separate, but related concern which looks like it has been discussed here on the forum.

1 Like
Spec review PRs
2

These are interesting, thanks for sharing!

Standardized Metadata Records for Spaces

From the opensocial.group perspective, it feels nice to be able to enumerate this kind of metadata without needing to synchronize/fetch a metadata record from each individual space. Especially for space types (modalities) which the displaying app might not have permission to synchronize (aka, might not have OAuth scopes to synchronize spaces of a given type).

From the perspective of public spaces and wanting to do cross-app preview cards, that feels like a generic thing that all spaces might want to support, not just opensocial.group spaces. Maybe a community.lexicon.* description record would make sense?

Announcing a Space Publicly

I think there is something to this. I’m not sure if opensocial.group is the right abstraction layer to handle it though. On the one hand it might be a generic need for all public spaces, not just opensocial.group spaces, and a more generic declaration might be good. On the other hand it can also be helpful in the public broadcast protocol to have distinct record types for different modalities (eg, to help backfill using listReposByCollection).

I almost feel like using the space modality as a record “collection” (NSID) might make sense (with the record key matching the space key), but that is probably too clever/confusing.

Providing a Default App for Space Links?

A bit of a broken record, but this also feels like a more generic issue than opensocial.group, or even spaces. My general take on this is that is a problem for the displaying app to solve, using the record type and/or space type in the URI. It makes sense to have some fallback mechanism to hint to apps how to construct an app URL for content types they don’t know about, but it feels like that could be as simple as a collectively-maintained JSON file in a git repo somewhere, or some way for lexicon developers to declare default URL patterns by publishing a record.

2 Likes
3

Yeah, good point. In my head I was subconsciously batching it all into opensocial.group since it was the first “generic” standard on top of ATProto spaces. But I think you’re right that all these points are basically universal, regardless of the group host standard for the most part.

Oh, I didn’t think about the oauth scope to synchronize different types of spaces. That’s a little annoying for the general-purpose link-card type use-case.

And it’s also problematic in many cases to have access to the space’s metadata be separate from the space’s own access. I’m imagining title’s like “What are we going to do about @some-user’s behavior on the forum?” in a private space for moderator chats, and that not being appropriate to show to the whole group.

It does make me think that maybe for the link-sharing use-case that the link metadata should be wrapped up in the chat message when someone sends it, so you’re essentially re-posting to the metadata to the app, instead of expecting the app having to get it from the space.

That has the same metadata leakage problem, but the app can be clear about that in the chat preview that it’s showing the title ( and let you remove it and just paste the bare link ).

I know. :joy: The case is even stronger for doing something a little too clever now that I think about listReposByCollection, which hadn’t occurred to me yet. Also relevant is jetstream filtering.

Honestly doing a weird sub-domaining to the collection where the declaration record for a space.roomy.channel would be, for example, community.lexicon.space.declaration.space.roomy.channel/tid might actually be a good solution. I think you don’t need to worry about the tid matching the space key since you still need to put the full at:// URI in a record field anyway.

I know you’re not supposed to “generate” collection IDs, but in this case it does map one-to-one to an actual space type lexicon.

4

So, continuing to think about this, focusing on space metadata: what would people think about using standard.site to describe things like forum threads?

@schlage.town @awarm.space, trying to find standard.site people to ask about this because it’s actually something that was somewhat unclear to me about standard.site: what is the scope of standard.site do you think? Should we not use it for things like forum topics or chat threads?

It’s super generic and provides basic metadata that is pretty universal, but should it stay used for pretty blog-like data?

Group stuff is still obviously nascent, but are there people interested in adopting a universal “thread” lexicon similar, at least in principle, to standard.site?

1 Like
5

Hey yeah good question! Personally I think it’s better for standard.site to stay focused on longform blog-like content. Not that it has to be strictly blogging only, I think it’s a bit fuzzy and that’s fine, but yes I’d say something like forum threads should be a different lexicon!

This has come up before b/c it’s not super well defined and there are definitely cases where folks want to use it even where (imo) it doesn’t always make sense. In a reply a while back to a similar q in signal I said:

Yeah, imo a bit broader than blogs but definitely narrower than any content on the internet haha.

Easier to think in terms of why you’d want to publish as standard.site, so less about ‘could the data technically fit into these lexicons’, more about: does it fit the use case of social reading and publishing?

Would readers want to find this content in discovery tools? Would I want to see if my mutuals are publishing this kind of thing?

So, things like web comics, serialized novels, journalism, project newsletters — yes! Status logs, patent records — I think no. Of course some ambiguity / grey area but maybe that’s a helpful way to think about it?

Reasonable for folks to disagree on exactly where the line should be but just for me at least I don’t think I’d want to see forum / chat threads e.g. in a reader app or discovery tool, though I’d be into a similar thing more for that purpose!

2 Likes