Hi Ewan!

What do you think everyone?

It's a nonbinding resolution. I'm in favor of passing it.

What are some?

cool

Wait... what? Slow electrons? I thought that usually electrons/electricity travels pretty close to the speed of light.

You should define what these do? Is 'response' long-polling?

I'd just remove this sentence since it just begs my questions but doesn't answer them. Maybe move the definitions down to the 'Grip-Hold' header def below

typo

What about Lions?

It's not really clear to me what the value of this should be... Does it matter?

Before I can test, I need to deploy my django app so its available on the public internet. And, oh, maybe this is what you meant by "Origin Server destination" above.

It's likely that 99% of people following this guide are devving on localhost. It would be sweet if you showed them how to use something like localtunnel to tunnel their dev box to a public url that fanout cloud can reach. https://localtunnel.github.io/www/

I think you mean 'lets Fanout Cloud integrate'

This period looks like it should be in the header value, but it shouldn't be.

Why have these colon characters here? AFAICT they're not actually supposed to be sent in the Authorization header

I hate that there is so much trash left behind, but I have to wonder if there is any practical reason for this policy. Add more trash cans.

users flock to free. Will it stay free forever? If not, what about all those projects? :(

Not to be confused with 'origin' property

This implies that the inbox URL MUST respond to a GET request, but doesn't explicitly require it

Who determines when an activity can be transient? A receiving server can apply whatever logic it wants (e.g. everything is transient to limit storage requirements)

I think better to throw a Bad Request error than silently ignore parts of the request body

Even if there already is an .id ?

I think this requirement should be removed. It's overconstraining.

What does this mean? Elsewhere in the document, the only time 'discovering' is used is wrt discovering an inbox or outbox, not a 'profile'.

Hmmm. I'm curious what you mean by this?

I chose this one. "hmm what is Sojourn?"

I think you mean 'queue'

In AS2, the domain of the 'actor' property is said to be only 'Activity'. The class of Activities is disjoint from the class of Objects. i.e. 'actors for all objects' doesn't make sense to me in the context of AS2 as objects cannot have actors.

Let's say the Activity was "Ben Liked the Note by Amy". Then for the purposes of notification it seems like the more important properties would be .attributedTo (Amy) and .url of the Note itself (looking for a Inbox for the Note?).

I assume this means 'the activitystreams#to, activitystreams#cc, and activitystreams#bcc' properties, but

1. I would have no idea if I weren't so famliiar with the specs, esp since 'bcc' isn't in these examples.
2. in Example 11 '.published' and '.object.published' are the same value. Is this because the published value was copied during transformation to a Create activity? Or because the Note and Activity creation happened within the same second?
3. In Example 11, where did .object.id come from? Other sections talk about generating ids for activities, but not for sub-objects
4. In example 11, the addition of .object.attributedTo, .actor, and the inclusion of '@language' in the Note's @context (but no description of how/why it was modified from the original value in Example 10) distract from the point of this section and make it hard to know what's required of an implementation

Will you just enumerate the properties that must be copied? Or otherwise more clearly specify the transformation algorithm?

Wow. Straight to alarmist! Way to lose centrists in the opening sentence.

Why is this highlighted? Was hoping to click and see an annotation or hyperlink.

Woah woah woah! Definitely post it. Just maybe consider marking it as un-verified. Or inviting verification.

Some of the best (and worst, but tolerable) parts of the web are posted right after a thought enters your mind. I think self-censorship makes the web worse.

consider describing conceptual relation to as:Collection?

update: ActivityPump does this

This has more in common with the "Federation Protocol" part of the charter than "Social API", which is chartered as "A document that defines a specification for a client-side API that lets developers embed and format third party information such as social status updates inside Web applications."

Proposal: Rename this to "Social Web Federation Protocol" or if it turns out to be more informative than normative, "Architecture" and not protocol

URIs can always come back, and 410 is cacheable. IMO 404 is better

From RFC2610

Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.

This implies linear storage requirements, which isn't ideal. IMO 'MAY' or less is better.

Proposal: Consider SIP Specific Event Notification or a redux of it for HTTP/W3: https://tools.ietf.org/html/rfc6665#section-3

Also I know @progrium has thought a LOT about this over the last 5+ years. https://github.com/progrium/http-subscriptions/blob/master/SPEC.md

leave to content negotiation

I would leave only this part in and delegate the preceeding to paragraphs to Social Data Syntax (e.g. as:Collection for JSON)

If 'MUST', ALL of the contents (even if 1billion), or is a subset ok?

Is it worth even being specific about 'Bearer'? Other Authorization header types are sometimes reasonable too, and other good ones will likely be invented in the future.

IMO if auth{z,n} means is considered orthogonal, the most normative this group should be is "Use the Authorization Headers" and maybe descriptions of reasonable status codes to use.

Thanks for making this!

This is hard to keep i sync. i.e. how does a reader of this Collection know if the subject is still following?

Would be better to reify that 'Following' relation (e.g. call it a 'Subscription') and give it a URI on the subject's domain that can 404 once it is removed.

+1

Though a narrower goal of ways of expressing interest in topics may be more tractable and useful

Just sketching.

Profiles could publish a document listing a set of topics they are interested in receiving Content for. Friends or aggregators could then use this to be informed when to send things to them (e.g. when syndicating an activity with tags in that set)

There's more to HTTP then just the method. For example, if the client requests with GET and 'Accept: text/html', the server probably shouldn't be required (MUST) to respond with JSON. http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html

Many indiewebers only support responding with html right now, which is fine because it can be marked up in such a way that JSON can be extracted. Furthermore, this extraction could be the basis of those same resources supporting responding with Content-Type: application/json.

recommend (e.g. HTTPS URI)

without e.g. qualifier it's unclear if the parens are for example or equivalence

typo. You want "indenpendently"

and machines. Conversational computing is coming on quite strong (see Magic, Facebook M, Alexa, Siri)

It's extremely unclear whether and/or when POSTing to outbox is semantically to initiate an activity or to publish that one happened. I think it can't be both at the same time.

IMO POST /outbox should have "This activity was performed by actor" semantics instead of activity-initiation semantics.

Leave activity-initiation and CRUD to other RESTful (or not..) control planes, but give them a way of putting it in the outbox so that the outbox can be GET as a user's activity feed.

Edit after thinking for a bit: The sort of side effects initiated by activity described at the end of this document are a sort of interesting idea to be able move the fulfillment logic to a server and out of a client, but IMO that should be a separate thing. like POST {activity} to /initiate or something. That's different than POST {activity} to activity-log. Not sure which is best for /outbox to be, but I don't think it can be all at once.

DELETE via POST is bad because intermediaries have to understand the semantics of the post body in order to do e.g. cache invalidation or ACL inforcement.

Doesn't look deleted to me

What if I as a client submit two of these in a row?

What if the object's @id is 'http://facebook.com' (or another thing that the outbox server can't know how to update?). 400 Response? and it doesn't get in outbox?

But what if I, say, did update some resource through another program, and want that update to appear in my outbox?

In general, submitting an activity to trigger a side effects in a federated model seems like a diffcult thing to get right... It seems more tractable to lay out a way for other servers on which you update things to deliver a receipt for that activity to your outbox.

What about 'private'?

"Ben just weighed himself" may be useful to have in my personal outbox, but I def don't want to share that. :)

Only a concern because of earlier language of default recipient list being all your followers

What does that mean? Can't find 'share activities' mentioned elsewhere.

Even those recipients in other federated spaces? That's a lot of MUST.

Another reason the dereferencing algorithm should support service delegation is so that if all these objects all delegate to same receiver, then only one request has to happen.

"origin servers of the new activity's constituent objects"

Later section says that the default recipient list is implementation specific, but MAY be this.

I think this is a typo. What does it mean?

What if there are 1 million people in the Collection? Why not just delivery the inbox of the group?

We have this problem in real world (where group is all users of cnn.com following 'world news') and do something like the above.

definition?

activities?

of... activity.published? or activity.updated?

the following example as "itemsType", but I don't see that defined in this document or AS Core/Vocab

Why can't the ID or URL just support requesting as JSON?

OAuth 2.0 on it's own doesn't fully prescribe how to do this.

OpenID Connect does (on top of OAuth2). Maybe other things too, but it's the most useful user authentication extension I've found.

Says HTTP here but not in below part, where it just says 'Valid URI'

URIs can always come back, and 410 is cacheable. IMO 404 is better

From RFC2610

Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.

Consider supporting activity pump service discovery (and delegation) for those URIs like webmention does

So... loops. They can happen in here right? How do we prevent? There needs to be base cases.

Or something like: After you successfully send an activity to an inbox endpoint, you add that endpoint to the message somewhere. Other endpoints you notify can see endpoints its already been submitted to. If you receive an activity that is already submitted to other endpoints, you MUST not submit it there.

link?

Consider adding a fourth discovery layer of whole-domain delegation via .well-known. http://indiewebcamp.com/irc/2015-11-29#t1448856141695

(this could also just be documenting how to use webfinger for this)

This lets one domain delegate all its webmentioning to another provider without having to adjust server code to add new response headers or HTML

which? Kind of ambiguous without an example.

Seems like this should be SHOULD. The former requires emailing someone at IESG. The latter is wiki-based.

Consider linking to something like http://patterns.dataincubator.org/book/qualified-relation.html

Not as simple as not having those extra properties and convention at all, and just having language maps in range of displayName, title, and future properties where it makes sense. Relevant, but not clear what the outcome was. https://github.com/json-ld/json-ld.org/issues/133

vague

Why not include this in the specification document?

I think it's more that they're trying to focus on the present that takes the form of an article. Hipster atomic-news is < 1%. They want instant content liquidity by being able to ingest 99% of today's news sources.

http://www.teawithstrangers.com/

Ankit is really nice!

Relevant: It's not uncommon for parental insurance to extend through 25 now!

THIS. Was definitely a feeling I had after about a few months of moving to SF at 19

The argument isn't really quoted for this conclusion...

Been there. Several company fundraising parties I couldn't get into.

Me too!

:) #mlgen

Anecdotally, youngsters tend to dress to impress to be taken more seriously. Unfortunately, this takes capital, and not everyone has equal access.

I felt very very crazy while in college in Kansas. No one was teaching web engineering or product development, and no one at any age was practicing it that I could see and spend time around.

http://lmgtfy.com/?q=nerd+night+sf

Yep. SF is a better place to be 18-24 than Kansas.

IMO this is the most common. And extremely rational. 1$ today is worth ~$1.35 after 4 years of college. And that extra $0.35 can make you $3.50 over 30 years.

Surely it's not the same as http://missioncontrolsf.org/?

Whoop dee do

Comment!