Lynnesbian 
you know, neither pleroma nor mastodon are perfect. pleroma needs image captions, although it already supports adding them from the mastoFE so really it's a minor issue because you don't have to use the pleromaFE. mastodon needs nodeinfo, which is the best kind of glaring omission because users don't notice it missing and blame other software for not working with mastodon when it's really mastodon's fault for not working with everyone else. they're both equally flawed
does this seem rude or anything?
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 (which is based on Mastodon), 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.
the GH issue is here btw:
https://github.com/tootsuite/mastodon/issues/6739
https://github.com/tootsuite/mastodon/issues/6739
pls dont dogpile
Ben Lubar (any pronouns)@lynnesbian I'm reading it and finding myself agreeing with Eugen based on what information is available in that thread.
I'll check the spec that people linked to next.
@ben even if the standard isn't perfect, it'd be nice to have *something* universal
AP isn't perfect either
Scarly the Raven@lynnesbian @ben some things are adopted as standard practices without some standards body enforcing the conventions and that is fine, organic and completely valid
if every single programming convention had to have a corresponding standard before being adopted, then we would still be using assembly due to the tremendous friction that this would add to the development of software
if every single programming convention had to have a corresponding standard before being adopted, then we would still be using assembly due to the tremendous friction that this would add to the development of software
@scarly @lynnesbian the issue I saw was that the spec seems to be inconsistent with itself.
Pleroma seems to implement nodeinfo 2.1, which does not exist as far as I can tell.
Eugen Rochko@scarly @lynnesbian @ben My concern is, if it shall become universal, I'd much rather prefer it was as close to perfect as possible, because once it's universal, there won't be getting rid of it.
Forget governing body if we can't get it, my wishlist is just: Let's use JSON-LD for consistency, let's use a single well-known URL, and well thought-out property names.
@Gargron @scarly @ben honestly, it's already pretty close to universal. like i mentioned in the github issue, GNU social and mastodon are the only two instance types i've been able to find that don't support it. they all use the same URL format of /.well-known/nodeinfo, so while the standard may not be finished yet, it's about as close to universal as it can be without mastodon using it too.
@lynnesbian @scarly @ben It's not near universal yet for the simple reason that there are a magnitude more Mastodon servers than other software. Counting by projects does not make much sense in this context I think. Also, the nodeinfo well-known URL actually must contain a link to the actual real URL, which is my issue with that.
@lynnesbian @scarly @ben host-meta is an outdated standard that is no longer used. The final webfinger spec actually simply defined a well-known URL for webfinger, that is always the same.
@Gargron @scarly @ben i actually didn't know that, huh
hubzilla must use an outdated version then
i just wish there was a universal standard for these things. it doesn't have to be nodeinfo, but i feel like doing something that isn't nodeinfo would require a lot more work (because of all the software using it) than implementing nodeinfo would, and adding nodeinfo still leaves the possibility of moving to something else later.
The "usage" key *requires* that the "users" subkey is present, but it can just be an empty object, which leaves me wondering why they bothered to require it in the first place.
The "outbound" part is also puzzling. It has stuff like atom and rss, which make sense, but then there's stuff like "google" (does that refer to Google+? or that the site can be searched with Google web search? or that Google Translate isn't explicitly blocked?) and then there's stuff like "smtp", which isn't a protocol you can read stuff from at all.
"openRegistrations" also strikes me as a mostly useless key because there's no way to actually specify how to register.
Protocols isn't useful because discovering whether a protocol is supported but not where the endpoint is is useless and if you already know where the endpoint is, you can just check to see whether it's supported via that.
The only keys in the entire document that might be useful are the ones under "software", which is just the Server http header.
Marmy ♡@Gargron you already know that using JSON-LD will not be used by all fediverse software and will not be consistent