Trim off nodeinfo attached to user in the API #827

New issue

Open

opened 2024-08-17 13:46:12 +00:00 by xarvos · 2 comments

xarvos commented

2024-08-17 13:46:12 +00:00

While mastodon's nodeinfo is relatively slim, nodeinfo for misskey and especially pleroma/akkoma are particularly large and can go up to more than 10KB uncompressed. This significantly increases the response size. I have measured the nodeinfo-to-status size from 40 posts in home timeline (consisting of mostly mastodon posts) and 40 posts in bubble timeline (consisting of only akkoma's posts) and the ratio is respectly 28% and 60%, which is quite large.

As it's only used to show software version and favicon, I suggest filtering for only those information to send via the API, as other information is not normalized across fedi software and not useful anyways.

Some API endpoints I found that include this info (there might be more):

timelines, e.g: /api/v1/timelines/home
notifications: /api/v1/notifications
status: /api/v1/statuses/{id}
thread: /api/v1/statuses/{id}/context
account: /api/v1/accounts/{id}

Here are the scripts I used to measure average nodeinfo-to-status ratio:

#!/bin/bash

function record() {
  witchie status $1 --json > response.json
  jq '.account.akkoma.instance' response.json --compact-output > nodeinfo.json
  echo "$(cat response.json | wc -c),$(cat nodeinfo.json | wc -c)" >> records.csv
}

echo "full,nodeinfo" > records.csv

for status_id in status_ids  # replace with the status ids, obtained by e.g. witchie timeline -c 40 -1 | grep ID | awk '{ print $2;}' | xargs
do
  record $status_id
done

from csv import DictReader

full = 0
nodeinfo = 0

with open('records.csv') as f:
    reader = DictReader(f)
    for row in reader:
        full += int(row['full'])
        nodeinfo += int(row['nodeinfo'])

print(nodeinfo, full, nodeinfo / full)

Currently, the entire nodeinfo of a user's instance is attached along with a user in response. As far as I'm aware, this is only used to show their instance's software + version and favicon in akkoma FE. While mastodon's nodeinfo is relatively slim, nodeinfo for misskey and especially pleroma/akkoma are particularly large and can go up to more than 10KB uncompressed. This significantly increases the response size. I have measured the nodeinfo-to-status size from 40 posts in home timeline (consisting of mostly mastodon posts) and 40 posts in bubble timeline (consisting of only akkoma's posts) and the ratio is respectly 28% and 60%, which is quite large. As it's only used to show software version and favicon, I suggest filtering for only those information to send via the API, as other information is not normalized across fedi software and not useful anyways. Some API endpoints I found that include this info (there might be more): - timelines, e.g: /api/v1/timelines/home - notifications: /api/v1/notifications - status: /api/v1/statuses/{id} - thread: /api/v1/statuses/{id}/context - account: /api/v1/accounts/{id} --- Here are the scripts I used to measure average nodeinfo-to-status ratio: ```bash #!/bin/bash function record() { witchie status $1 --json > response.json jq '.account.akkoma.instance' response.json --compact-output > nodeinfo.json echo "$(cat response.json | wc -c),$(cat nodeinfo.json | wc -c)" >> records.csv } echo "full,nodeinfo" > records.csv for status_id in status_ids # replace with the status ids, obtained by e.g. witchie timeline -c 40 -1 | grep ID | awk '{ print $2;}' | xargs do record $status_id done ``` ```python from csv import DictReader full = 0 nodeinfo = 0 with open('records.csv') as f: reader = DictReader(f) for row in reader: full += int(row['full']) nodeinfo += int(row['nodeinfo']) print(nodeinfo, full, nodeinfo / full) ```

Oneric commented

2024-08-20 19:02:29 +00:00

Member

It’s in theory possible other frontends or apps use more of the currently included information; user responses containing metadata about their instance is documented API behaviour.

If/When this is trimmed it’s probably a good idea to survey usage across more FEs /apps first.

It’s in theory possible other frontends or apps use more of the currently included information; user responses containing metadata about their instance is [documented API behaviour](https://akkoma.dev/AkkomaGang/akkoma/src/commit/3bb31117e65079d710e5129eb70c946d4ffe99ff/docs/docs/development/API/differences_in_mastoapi_responses.md#accounts). If/When this is trimmed it’s probably a good idea to survey usage across more FEs /apps first.

xarvos commented

2024-08-23 14:00:46 +00:00

Author

Still, even if we want to keep the behavior to avoid breaking these theoretical clients, we can still have an extra params, say ?trim_instance_info=true or maybe instance_info=full|minimal|none, that'd also work.

But as it's not an urgent issue, I agree that it's better to discuss the solution carefully.

Afaik, there's not a client specific to Akkoma; all of those are Mastodon-first client that can also support Pleroma and Akkoma (of which only Akkoma has this). Also, as said above each instance software has its own schema for nodeinfo, so I can't imagine clients doing anything useful with those without fallback. Still, even if we want to keep the behavior to avoid breaking these theoretical clients, we can still have an extra params, say `?trim_instance_info=true` or maybe `instance_info=full|minimal|none`, that'd also work. But as it's not an urgent issue, I agree that it's better to discuss the solution carefully.

No milestone

No project

No assignees

2 participants

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: AkkomaGang/akkoma#827

No description provided.