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

Specify service discovery of inbox/outbox via link relations #50

Closed
gobengo opened this Issue Dec 2, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@gobengo
Copy link

gobengo commented Dec 2, 2015

e.g. via LInk Headers or Webfinger

https://hypothes.is/a/Gs-sk9MbQAq_V7pslc4HrA

@cwebber

This comment has been minimized.

Copy link
Collaborator

cwebber commented Dec 4, 2015

Context: we agreed to do this at the SocialWG face to face. The current mechanism (embedded json-ld) was a placeholder.

@cwebber

This comment has been minimized.

Copy link
Collaborator

cwebber commented Sep 11, 2016

So I've been giving this a lot of thought. When I originally agreed to this, I hadn't had enough implementation experience. I think my views have shifted a bit.

My own server/client implementation currently uses content negotiation to request the activitystreams representation of some URI, including actor URIs. Thus I could have both an HTML and an AS2 representation of my profile.

I could also support link relations. However, I'm not wild at all about adding a requirement for HTML parsing into this specification. I have a client written in emacs lisp... HTML parsing is not available easily there, and it isn't available in a number of other languages so easily either. HTML parsing is no simple thing. I don't really want to require it.

Luckily, link relations can be done via HTTP. Horray, we could support link relations via HTTP, too!

However... what's the real motivation and value of link relations when we have content negotiation? It seems like the main advantage is that we could support a user's URL at a static site, or some other homepage. That seems like a nice feature, but doesn't seem worth being the canonical way to retrieve an actor's profile object.

So how about this instead? Clients MAY use link relations, either via HTTP or via HTML parsing, to find the canonical Actor URI. But this is just a friendly redirect, the way that you find an RSS/Atom feed. The actor's id is still the thing pointed at via the link relation, and that's what's used in the protocol generally. And you still specify an Accept header to get the profile object. That way we can support the "static site" approach but not require that clients use it, or have that be mixed into anything else in the document.

WDYT?

@cwebber

This comment has been minimized.

Copy link
Collaborator

cwebber commented Sep 11, 2016

I just realized that the inbox being possiblye descovered by a link relation is covered by LDN anyway, which we reference, so I think we're good enough on this issue :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment