Aaron Parecki

@sikkdays okay weird, I will take a look at the email flow! Thanks!

@sikkdays I'm still stumped on the Instagram issue, but post by email should be working.

@MailChimp Thanks! So if I wanted to programmatically create content in a weekly newsletter, I should create a new campaign every week?

@JawboneSupport Just had a nice chat with support and am getting a replacement. Thanks! Hope I don't have to call you back in another 8 mos!

@joshmarinacci sure! you have it already

@joshmarinacci Yours is much prettier than mine is going to be, since I'm writing an OAuth client. #AppleTV

In reading this over, I noticed a subtle difference from the Facebook and
Google implementations, and I'm wondering if this was intentional or not.

Section 3.1 says "The authorization server prompts the end-user to
authorize the client's request by entering the end-user code provided by
the client." The introduction has even more explicitly different wording:
"(D) ... If the end-user agrees to the client's access request, the
end-user enters the end-user code provided by the client."

However this is different from Facebook and Google's implementations, which
work as follows:

- Device shows the verification URI and code to the user
- The user visits the URL and is prompted to sign in to the service
(Google has the extra step of then choosing which Youtube account to use)
- The user is then prompted to enter the device code
- After entering the device code, the authorization prompt is displayed

In reading this draft, the implication is that the act of entering the code
also is the authorization. The problem is that the server won't know things
like the scope or application name until after the code is entered, so it
can't properly show an authorization prompt.

I think this needs to be reworded to separate entering the code from
showing the authorization prompt. I believe it is only a wording change.
Maybe something more like:

3.1 "The authorization server prompts the end-user to enter the end-user
code provided by the client, after which it prompts the end-user to
authorize the client's request."

and in the introduction:

1. (D) "The authorization server authenticates the end-user (via the
user-agent) and prompts the end-user to enter the end-user code provided by
the client. The authorization server validates the end-user code and
prompts the end-user to grant the client's access request."

@whaity There are some notes here http://indiewebcamp.com/Jekyll and several people are doing it!

@whaity Start posting tweets to your own site, then it won't matter as much to stop using Twitter #indieweb

@tinokremer Plus, using SquareSpace as a web host is a perfectly fine solution as long as it's on your own domain. #indieweb

@tinokremer Actually @leolaporte has a @withknown site too! http://www.leoville.net #indieweb

@whichlight @t @MIT #indiewebcamp we went out for lunch! We're meeting at the Cambridge Center Roof Garden.

@rhiaro that is a long list! I vote for: "Make various feeds discoverable" and IndieAuth

@chels_bar hai! Send me your email address to aaron at parecki .com! btw will you be able to make it to IndieWebCamp MIT this weekend?

The definition of properties such as content allow for HTML markup to be included. However, the spec does not require that the media type be specified. This leads to inconsistent results when the consumer doesn't know what to expect.

For example, if the "content" property *can* contain HTML, a consumer will be either stripping the HTML, sanitizing it, or displaying it directly. However, if a user enters something like "I had a great time at the View Source conference <o>", (<o> being an ascii representation of the conference logo), the consumer would need to HTML escape that before rendering it otherwise it would disappear from display. However there is no way to know whether the value is meant to be the literal text or interpreted as HTML.

Additionally, the current spec does not allow for different media types for summary and content, since the mediaType property lives next to those properties. The following example demonstrates the problem:

```
{
"@context": "http://www.w3.org/ns/activitystreams";,
"type": "Note",
"mediaType": "text/html",
"summary": "Hello <o>!",
"content": "<b>Hello &lt;o&gt;!</b>"
}
```

My suggestion is to require that string values can *only* be plaintext, and if you want to have HTML for a value, then you enclose it in an object where you can specify mediaType. This would look something like the following, I'm open to suggestions on names:

```
{
"@context": "http://www.w3.org/ns/activitystreams";,
"type": "Note",
"summary": "Plaintext summary, always HTML escaped <o> before displaying",
"content": {
"type": "Object",
"mediaType": "text/html",
"value": "<p>HTML content goes <b>here</b></p>"
}
}
```

@obensource #viewsource It's so close to my old Nerdhaus logo! <n> http://wiki.projectnerdhaus.com

@kylewm.com I'm getting really interested in private/friends-only posts as well, ever since I started posting things in the XOXO Slack more often. I'm finding these community-oriented networks allow me to say things there that I wouldn't want to post publicly. Not even so much as a privacy thing, but also just because the audiences are drastically different, people know what to expect when I say something in the #cocktails xoxo channel, and that's very different from what you'd see in the #pets channel. Great example is I don't really want to post a ton of cat pictures publicly on my site, but I do share pictures in the #pets channel!

@wctek Awesome, thanks! This is working out great so far! https://instagram.com/p/9cokcWjcnM/

@mager @wadey @schuyler @mjmalone I was able to do it in ArcGIS Online: http://arcg.is/1P04QqI Shows the % area in each zipcode for my input