I’m building some more federation tools that involve Diaspora and the fact that it runs an outdated webfinger service is increasingly turning into an issue. Most of the world has started to move towards RFC7033 since it was standardised last year - basically a JSON-based webfinger that allows you to lookup information for a single “pod” with one fetch.
Currently, if given a webbie (D* handle) the discovery process looks like:
- try RFC7033
- if that fails, fall back on https: host-meta webfinger
- if that fails, try again using the http port
- if you get something parse it.
- This provides hardly any information except for a personal XRD template. Fill it in and then fetch the personal XRD file.
- We can now discover it’s Diaspora.
- Since it’s Diaspora we need to fetch the hcard and parse it for all the extra goodies like name and profile photo and visibility
- If this were a statusnet connection we would need to also fetch/parse the atom feed to see if there’s a pubsubhubbub server defined.
- if all that fails, check if it’s an email address
Anyway as you can see this starts to add up to a mountain of HTTP requests and invoking different parsers with different rules just to look up one person. Ideally it would be nice to get it all in one or at most two slurps of JSON. Then we can react in close to real time rather than queue the request in the background and report something like “And nobody was found”.
It’s OK to keep the old facility as it will take time for everybody to migrate and make use of the new one. It just makes the whole discovery process much simpler and less resource intensive.
This also doesn’t really impact the “federation protocol” which I know is an open issue. No matter what D* does - if it supports any kind of user@host addressing going forward you’re going to need webfinger. The new version is much more efficient than the old one in a number of ways and is almost trivial to implement.
Note: This discussion was imported from Loomio. Click here to view the original discussion.
First off: Mike, I’m glad to see you participating in these discussions. It’s always great to see active members of other decentralized projects make suggestions based on their experience.
I’m personally all for this, especially if the implementation isn’t hard to implement, and it brings greater improvements to the way we currently use Webfinger.
and is almost trivial to implement
This could be the deciding factor.
Good call though Mike, this would get my vote!
I don’t think anyone would reject a backwards compatible implementation for this. So any contributions are welcome.
Sounds good - would you be able to/interested to write the code @mikemacgirvin or shall we raise an issue and promote this to our community devs?
I guess at first would be just to start using RFC7033 as the first option - and then work on improving things like person lookups.
I’m thinking a D* dev who knows the code base could do it much more efficiently than I; as I’m pretty well bogged down in redmatrix features and haven’t really looked at the D* tree in about 3 years.
The person lookups are part of the new webfinger protocol. Some projects can do one fetch and be done. Redmatrix was a bit more difficult as we provide information in a person lookup for which there isn’t any clean representation defined in the RFC (directory services, arrays of locations of nomadic identity clones, etc.). So we did it with two fetches. The RFC7033 fetch tells us the site has zot as an available protocol, and provides a pointer to the zot-info (JSON) packet for the channel/pod requested. Retrieving this provides 100% of the information we need to communicate with and link this channel/pod into the network.
GNUsocial is doing what I consider a good job at migration - it’s really just a mirror of the older XRD information, converted to JSON. We would still have to parse the hcard and feed (both XML) in that case but we’ve already saved two fetches because all the info from the old “personal XRD” is supplied with the first fetch.
I never looked at webfinger, but the old standard sounds like some complicated stuff. So it would be great to simplify this.
@mikemacgirvin Hopefully you will implement it in red in a modular way so that we can integrate it into friendica with low effort.
And hopefully some day we will have a common protocol for the federation between different networks as well …
I’d love to see this implemented in the federation gem so we can have that “for free” when we migrate to it
It shouldn’t be very hard to implement. Internally the gem stores XRD documents as Ruby hash/arrays, so all we’d need is a
to_json method for that data.
@michaelvogel - fabrixxm has looked at rfc7033 for friendica - and you can steal a lot of what I’ve already done for red. Basically move the old xml/html stuff out of the xrd and vcard and into a json array. And see my latest post on D* about federation. We’re making huge strides.
Proposal: Implement RFC7033 (webfinger)
first time using this loomio feature, not sure i’m doing right suggesting we raise the following thread to a feature proposal
Outcome: Jonne was right. No controversy here.
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
Proposals are only necessary if there’s controversy. I don’t see any here.
terrific! i sense that this would be worthwhile, webfinger seems to be evolving as an important part of basic interoperability with the growing ‘federation’, unfortunately my amazing technological abilities are of little use at this juncture only skilled ruby programmers may pull this off.