You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another option would be to serve the subset counts on the respective subdomains, e.g. https://bsky.brid.gy/nodeinfo.json#usage.users.total being the total number of Bluesky users whose account is being bridged.
That wouldn't necessarily tell the whole story, since it wouldn't say to which networks they are bridged, but it would work with existing surveying tools. Though, in that case maybe those counts should be excluded from the one that fed.brid.gy serves to avoid duplication in aggregate stats.
Another option would be to serve the subset counts on the respective subdomains, e.g. https://bsky.brid.gy/nodeinfo.json#usage.users.total being the total number of Bluesky users whose account is being bridged.
True! That would break up Bridgy Fed in fediverse stats aggregators into its separate protocols, one "instance" per protocol. Which is maybe fine? 🤷
Inspired by https://bsky.app/profile/did:plc:fdme4gb7mu7zrie7peay7tst/post/3lbabzmnccs2w
Would be non-standard, but if I namespace the field names, that should hopefully be fine...?
Nodeinfo spec: https://nodeinfo.diaspora.software/protocol.html
The text was updated successfully, but these errors were encountered: