Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose instance metadata as json-ld #6739

Open
pierreozoux opened this issue Mar 11, 2018 · 12 comments

Comments

@pierreozoux
Copy link
Contributor

commented Mar 11, 2018

In the context of https://github.com/TheKinrar/mastodon-instances and https://github.com/libresh/catalog it would be a great feature to be able to scrape information in an automated manner.

As an admin, I already fill these metadata (description, name...) in the admin interface.

Exposing them as json-ld would ease the automation around listing instances and hosters that offer mastodon.

@Gargron

This comment has been minimized.

Copy link
Member

commented Mar 11, 2018

There is no standard for "instance data" in ActivityPub, but we already have a REST API that does this: /api/v1/instance - mastodon-instances uses that + some extra info they have admins fill-in manually.

@Gargron

This comment has been minimized.

Copy link
Member

commented Mar 11, 2018

To be precise there is an emerging protocol for this kinda thing, but it's not JSON-LD afaik: https://github.com/jaywink/nodeinfo2

@pierreozoux

This comment has been minimized.

Copy link
Contributor Author

commented Mar 14, 2018

@Gargron is it a typo? Did you want to point to https://github.com/jhass/nodeinfo instead?

@pierreozoux

This comment has been minimized.

Copy link
Contributor Author

commented Mar 14, 2018

Created this issue also to know about json-ld: jhass/nodeinfo#19

@wiktor-k

This comment has been minimized.

Copy link
Contributor

commented May 21, 2018

It would be good to have nodeinfo, nodeinfo2 or something else standarized as being listed at https://mastodon.social/api/v1/instance/peers (or some other popular instance) automatically subscribes the domain to a bunch of crawlers trying several different URLs, some of them every 5 minutes!

@rhaamo

This comment has been minimized.

Copy link

commented May 21, 2018

https://github.com/jhass/nodeinfo would be the one to use, Pleroma is implementing it, and other servers like Funkwhale too.

@Gargron

This comment has been minimized.

Copy link
Member

commented May 21, 2018

{
  "version": "2.0",
  "software": {
    "name": "diaspora",
    "version": "0.5.0"
  },
  "protocols": ["diaspora"],
  "services": {
    "inbound": ["gnusocial"],
    "outbound": ["facebook", "twitter"]
  },
  "openRegistrations": true,
  "usage": {
    "users": {
      "total": 123,
      "activeHalfyear": 42,
      "activeMonth": 23
    },
    "localPosts": 500,
    "localComments": 1000
  },
  "metadata": {
    "chat_enabled": true
  }
}

From the example.json of 2.0 schema. Mind most properties are camelCase, but chat_enabled is snake_case, and activeHalfyear is neither (halfyear is not a word), plus the fact that those timeframes are super arbitrary.

It seems to still be in an early stage and I'm not in a hurry to adopt it (it also doesn't have an official body like a W3C working group behind it)

@rhaamo

This comment has been minimized.

Copy link

commented May 21, 2018

activeHalfyear etc. are not mandatory at all. users->total is the minimum, localPosts may be, the other one no.

and about "chat_enabled" it's the metadata field, which is free-form, you can use "chatEnabled" if you want.

@Sylvhem

This comment has been minimized.

Copy link
Contributor

commented May 21, 2018

(it also doesn't have an official body like a W3C working group behind it)

To be fair, we just adopted RSS, which is a non-standard and deprecated technology, even as Atom have been standardized by an official body, the IETF, more than ten years ago. So I'm not really sure it's a concern here.

@wiktor-k

This comment has been minimized.

Copy link
Contributor

commented May 23, 2018

It seems there are two problems (well, three if you count RSS ;) ): one is the location of statistics endpoints (currently hardcoded in crawlers as /api/v1/instance... etc.) and the statistics format. The latter will take some time to stabilize as there are multiple parties involved.

But the location of statistics endpoints - what various nodeinfo specs define as /.well-known/nodeinfo or x-nodeinfo-2 etc. could be stored in a place that is already defined: /.well-known/host-meta.

So Mastodon could add host-meta link with rel (e.g.) https://joinmastodon/ns#instance-info, pointing to /api/v1/instance, nodeinfo could use their own rel http://nodeinfo.diaspora.software/ns/schema/2.0 and crawlers could use one endpoint, that is standarized right now to quickly see what stats are available.

@Gargron Gargron added the suggestion label Oct 20, 2018

@Lynnesbian

This comment has been minimized.

Copy link

commented Feb 10, 2019

Any update on this? I'm writing a program that aims to work with as many different fediverse instances as possible, and I'd really like it if there was a standard supported by all of them. nodeinfo is used by Pleroma, Misskey, Friendica, Osada, Hubzilla, GangGo, Diaspora*, and probably others. The only instance types I've been able to find that don't work with it are GNU Social (which was last updated in late 2014) and Mastodon.

@brortao

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2019

Even GNU Social can serve nodeinfo via a plugin; see, for example, https://gnusocial.cc/.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.