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?

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

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions