pleroma/pleroma-meta

Fork 0

Feature set inconsistency and Feature Discoverability #61

New issue

Open

opened 2022-02-21 11:14:37 +00:00 by ilja · 1 comment

ilja commented

2022-02-21 11:14:37 +00:00

Member

The Sales pitch

Different platforms on the fediverse have a different feature set, which can lead to problems. For example, when someone from mastodon makes a post, I can emoji-react to it, but they wont see it. This is one example, but there are many. This leads to a bad UX because people can't easily be sure whether their actions will me noticed by the relevant people. This problem also leads to an incentive for implementations to implement an ever growing feature set, which is not sustainable in the long run.

One solution I see to this, is feature discoverability. Let's take the Emoji-react example again; We could imagine instances somehow advertising what features they do or don't support. That way Pleroma could let their clients know about what features are supported and the clients could present that information in a user-friendly way. (E.g. by giving the emoji-react icon a "dissabled" state when the target doesn't support this feature.)

Known ways in the wild

There are two examples of how features are advertised that I know of

On the individual object (both examples are actors)
- Pleroma has this for capabilities.acceptsChatMessages (but we don't actually use it)
- Smithereen has this for FriendRequests
Instance wide we have Nodeinfo's metadata.features

I added some examples below[1]. See also https://socialhub.activitypub.rocks/t/service-capability-discovery/630.

Practical

For Object specific things, advertising should be done by adding the relevant info as part of the object. Maybe the feature set should be a collection? (Y'know, since it's AP and all.)

A first idea if we want to keep track of instance wide features: We already have a table instances. We could add a new json column there with relevant nodeinfo. To keep it up to date we could fetch the Nodeinfo from newly discovered instances and then at regular intervals.

When a front-end fetches a post or account, we could make the supported feature list part of the json-object we return. This list is first loaded from the list on the instance level and then overloaded with the list of the object.

Maybe there are cases where a certain feature is relevant to e.g. a Note, but should be defined on the Actor level? In that case the overloading of the features list could be instance-actor-object.

We could wonder if such a layered way is needed. A Note whose instance can't handle emoji reactions now, may be able to handle them in the future. If we only pass the list in objects over AP and ignore the whole Nodeinfo part, then the older objects will show an outdated feature list. This may lead to some unexpected cases when someone interacts with an older object, but may be worth the trade-off to reduce complexity?

If a certain feature isn't advertised, we have to make our own assumptions. We can also let the front-end decide how to deal with missing information.

When doing this, we should share it in https://socialhub.activitypub.rocks/t/service-capability-discovery/630 so that other implementers know about it and can provide feedback.

Beyond

Even though this solves the problem of knowing what interactions can be done with other people, there is still a problem of how you want people to be able to interact with you. For example, they may want to invite you to a party, and you may want them to have that ability, but your instances software doesn't understand events. A work-around is to make an account on a different instance and tell people to invite that account, but that's not really a good UX either. This problem also leads to an incentive for implementations to implement an ever growing feature set (which is a problem we wanted to address here as well).

A solution to that problem could be nomadic identities, where one person can have multiple actors spread over multiple instances. The actor(s) who does have the needed feature, will receive the invitation. That problem is somewhat related, but otherwise completely out of scope for this feature/discussion.

References

[1]

# Pleroma
curl -s 'https://ilja.space/users/ilja' -H 'Content-Type: application/json; charset=utf-8' -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' | python3 -m json.tool

{
    "capabilities": {
        "acceptsChatMessages": true
    },
    ...
}

# Smithereen
curl -s 'https://friends.grishka.me/grishka' -H 'Content-Type: application/json; charset=utf-8' -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' | python3 -m json.tool

{
    "supportsFriendRequests": true,
    ...
}

# Nodeinfo
curl -s 'https://ilja.space/nodeinfo/2.1.json' | python3 -m json.tool

{
    "metadata": {
        "features": [
            "pleroma_api",
            "mastodon_api",
            "mastodon_api_streaming",
            "polls",
            "pleroma_explicit_addressing",
            "shareable_emoji_packs",
            "multifetch",
            "pleroma:api/v1/notifications:include_types_filter",
            "chat",
            "shout",
            "relay",
            "pleroma_emoji_reactions",
            "pleroma_chat_messages"
        ],
        ...
    },
    ...
}

## The Sales pitch Different platforms on the fediverse have a different feature set, which can lead to problems. For example, when someone from mastodon makes a post, I can emoji-react to it, but they wont see it. This is one example, but there are many. This leads to a bad UX because people can't easily be sure whether their actions will me noticed by the relevant people. This problem also leads to an incentive for implementations to implement an ever growing feature set, which is not sustainable in the long run. One solution I see to this, is feature discoverability. Let's take the Emoji-react example again; We could imagine instances somehow advertising what features they do or don't support. That way Pleroma could let their clients know about what features are supported and the clients could present that information in a user-friendly way. (E.g. by giving the emoji-react icon a "dissabled" state when the target doesn't support this feature.) ## Known ways in the wild There are two examples of how features are advertised that I know of * On the individual object (both examples are actors) * Pleroma has this for `capabilities.acceptsChatMessages` (but we don't actually use it) * Smithereen has this for `FriendRequests` * Instance wide we have Nodeinfo's `metadata.features` I added some examples below[1]. See also <https://socialhub.activitypub.rocks/t/service-capability-discovery/630>. ## Practical For Object specific things, advertising should be done by adding the relevant info as part of the object. Maybe the feature set should be a collection? (Y'know, since it's AP and all.) A first idea if we want to keep track of instance wide features: We already have a table `instances`. We could add a new json column there with relevant nodeinfo. To keep it up to date we could fetch the Nodeinfo from newly discovered instances and then at regular intervals. When a front-end fetches a post or account, we could make the supported feature list part of the json-object we return. This list is first loaded from the list on the instance level and then overloaded with the list of the object. Maybe there are cases where a certain feature is relevant to e.g. a Note, but should be defined on the Actor level? In that case the overloading of the features list could be instance-actor-object. We could wonder if such a layered way is needed. A Note whose instance can't handle emoji reactions now, may be able to handle them in the future. If we only pass the list in objects over AP and ignore the whole Nodeinfo part, then the older objects will show an outdated feature list. This may lead to some unexpected cases when someone interacts with an older object, but may be worth the trade-off to reduce complexity? If a certain feature isn't advertised, we have to make our own assumptions. We can also let the front-end decide how to deal with missing information. When doing this, we should share it in <https://socialhub.activitypub.rocks/t/service-capability-discovery/630> so that other implementers know about it and can provide feedback. ## Beyond Even though this solves the problem of knowing what interactions can be done with other people, there is still a problem of how you want people to be able to interact with you. For example, they may want to invite you to a party, and you may want them to have that ability, but your instances software doesn't understand events. A work-around is to make an account on a different instance and tell people to invite that account, but that's not really a good UX either. This problem also leads to an incentive for implementations to implement an ever growing feature set (which is a problem we wanted to address here as well). A solution to that problem could be [nomadic identities](https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse/2101), where one person can have multiple actors spread over multiple instances. The actor(s) who does have the needed feature, will receive the invitation. That problem is somewhat related, but otherwise completely out of scope for this feature/discussion. ## References [1] ``` # Pleroma curl -s 'https://ilja.space/users/ilja' -H 'Content-Type: application/json; charset=utf-8' -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' | python3 -m json.tool { "capabilities": { "acceptsChatMessages": true }, ... } # Smithereen curl -s 'https://friends.grishka.me/grishka' -H 'Content-Type: application/json; charset=utf-8' -H 'Accept: application/ld+json; profile="https://www.w3.org/ns/activitystreams"' | python3 -m json.tool { "supportsFriendRequests": true, ... } # Nodeinfo curl -s 'https://ilja.space/nodeinfo/2.1.json' | python3 -m json.tool { "metadata": { "features": [ "pleroma_api", "mastodon_api", "mastodon_api_streaming", "polls", "pleroma_explicit_addressing", "shareable_emoji_packs", "multifetch", "pleroma:api/v1/notifications:include_types_filter", "chat", "shout", "relay", "pleroma_emoji_reactions", "pleroma_chat_messages" ], ... }, ... } ```

ilja commented

2022-08-22 18:48:06 +00:00

Author

Member

This idea was shared and somewhat discussed on fedi: https://ilja.space/notice/AM9kzcoIUm4Vxo8p3w

Some notes from there:

We have the context from JSON-LD. This could already give a superset of what's supported and thus may be usable as a fallback
- E.g. checking for http://litepub.social/ns#EmojiReact and https://misskey-hub.net/ns#_misskey_reaction being available in the JSON-LD context namespace definitions would mean (custom) emoji reactions are supported on a post
- This can't be used completely because E.g. I have "https://www.w3.org/ns/activitystreams" in the context of my actor, but that implies Place is in the namespace, while it's not per sé supported.
BE should still allow sending things the "target" doesn't understand. E.g. an Announce is more for own followers than for the person who made the post. This can even be true for Likes. It should NEVER be interpreted as something like "no boosts allowed".
- It could be a visual queue in the FE. E.g. a greyed out option, or just a tooltip, or it could be configurable.
- Things can go wrong which makes it possible a server thinks something isn't supported while it is, so people should probably be able to ignore it.
The discoverability should be on the actor, not activities or other objects
- Changing/updating software means that the actor will now send a different list of accepted objects. Same isn't true for activities/other objects
- Having it per-post would allow implying "no boosts allowed" or "no replies allowed" on a post, which this is explicitly not about
- There's also nodeinfo, but that means fetching it from time to time and the features listed are pretty ad-hoc and not really described in an AP way.

There's also the question of e.g. using the content field in Likes or Announce. Not everyone supports that, but it's technically possible. Ideally we'd have a way that can deal with all that as well.

This idea was shared and somewhat discussed on fedi: https://ilja.space/notice/AM9kzcoIUm4Vxo8p3w Some notes from there: * We have the context from JSON-LD. This could already give a superset of what's supported and thus may be usable as a fallback * E.g. checking for `http://litepub.social/ns#EmojiReact` and `https://misskey-hub.net/ns#_misskey_reaction` being available in the JSON-LD context namespace definitions would mean (custom) emoji reactions are supported on a post * This can't be used completely because E.g. I have "https://www.w3.org/ns/activitystreams" in the context of my actor, but that implies Place is in the namespace, while it's not per sé supported. * BE should still allow sending things the "target" doesn't understand. E.g. an Announce is more for own followers than for the person who made the post. This can even be true for Likes. It should NEVER be interpreted as something like "no boosts allowed". * It could be a visual queue in the FE. E.g. a greyed out option, or just a tooltip, or it could be configurable. * Things can go wrong which makes it possible a server thinks something isn't supported while it is, so people should probably be able to ignore it. * The discoverability should be on the actor, not activities or other objects * Changing/updating software means that the actor will now send a different list of accepted objects. Same isn't true for activities/other objects * Having it per-post would allow implying "no boosts allowed" or "no replies allowed" on a post, which this is explicitly not about * There's also nodeinfo, but that means fetching it from time to time and the features listed are pretty ad-hoc and not really described in an AP way. There's also the question of e.g. using the `content` field in Likes or `Announce`. Not everyone supports that, but it's technically possible. Ideally we'd have a way that can deal with all that as well.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

pleroma/pleroma-meta#61

No description provided.

Rows
Columns