Socialwg/2015-05-05-minutes

Social Web Working Group 3rd face-to-face

05 May 2015

See also: IRC log

Attendees

Present

INRIA

Regrets

Chair

Arnaud

Scribe

sandro, rhiaro, aaronpk, elf-pavlik, bblfish

Contents

• Topics
  1. solid walkthrough: profile management
  2. Henry does Solid walkthrough on Private SHaring
  3. Comparison of Proposals
  4. next meetnig
• Summary of Action Items
• Summary of Resolutions

Summary of Action Items

[NEW] ACTION: pelf create comparison of side effects approach in MicroPub, ActivityPump and SoLiD [recorded in http://www.w3.org/2015/05/05-social-irc]
[NEW] ACTION: pelf document possible danger of malicious apps when moving more responsibilities to clients [recorded in http://www.w3.org/2015/05/05-social-irc]
 

Summary of Resolutions

1. Continue next week

---

Arnaud: plan for today is to go through two more APIs, activitypump and SoLiD

<cwebber2> hey Arnaud it says

<cwebber2> "the conference is restricted at this time"

Tsyesika: user posts a note

... posting a note to the outbox, you submit a Post activity with an object of a Note, sent to "followers"

... the server returns the entire activity with the note back, and it's added the author and publish date, and the ID of the activity and the object

... https://github.com/w3c-social/activitypump/blob/master/userstories/user-posts-a-note.md

Sandro: do you need the @type collection on the "to" object? Yes

<cwebber2> ok, I can't dial in since the conference is restricted, so I'll just follow via text

<sandro> cwebber2, what conference code did you use?

<cwebber2> sandro: SOCL

Tsyesika: the API requires you to specify the type, we could see about removing the requirement

<sandro> ah, sorry, but it's 26631 today

Tsyesika: to "to" is specifying the audience, not adding something to the collection, different from it being the target
... the server would lok at everyone you sent it to (the followers), and send it out to the inbox of everyone in the followers collection

<sandro> cwebber2, can you hear Jessica?

<cwebber2> yeah, it's a bit faint but I can follow

<sandro> yeah, she's mostly facing the screen, which is facing away from you

Tsyesika: there are two URLs involved here, the user's outbox "feed" and the "followers"

<cwebber2> sandro: no worries, it's sufficient

sandro: is this like access control?

Tsyesika: kind of, it's audience targeting but if the account is private then it acts as access control

Arnaud: can you tell us about the backend of distributing to the followers?

Tsyesika: it iterates through all the followers asynchronously and sends the full activity object to the inbox of everyone

Arnaud: so there are two resources that got created, one for the note itself, and one for the acitvity

Tsyesika: for updating a note, you specify the same note object but there's a new activity ID

<cwebber2> it's like email and collections are like email lists

sandro: if the following collection changes tomorrow, who has access to the previous notes?

Tsyesika: if I were to write the spec now, it would be available to the people who were in the collection at the time it was posted

sandro: so I could update the note and send the update to a different set of people?

Tsyesika: i don't think this is specified either

elf-pavlik: i'll make an issue for clarifying the ACL

Tsyesika: deletion, creating a deletion activity specifying the ID of the note
... a shell of the note remains at the original URL, which includes the deleted date. i'm going to open an issue to remove the publish/update dates from the deleted note
... the delete activity becomes activity 3

... next story: following a person

<bblfish> what's the URL

... https://github.com/w3c-social/activitypump/blob/master/userstories/following-a-person.md

<bblfish> https://github.com/w3c-social/activitypump/blob/master/userstories/following-a-person.md

<sandro> (To be more specific, the ACL issue is: how do the acls of a Note related to the recipient lists of the various activities which create/update that note)

<cwebber2> fyi it's totally cutting in and out so if someone addresss me I won't hear it

<cwebber2> wseltzer: might help

<cwebber2> we're entering into a user story I wrote up last night without being able to coordinate with Tsyesika

<cwebber2> and some of this behavior is different than the pump api

<cwebber2> a bit I think

Arnaud: the first step was the act of following, the second was the distribution of adding an activity?

Tsyesika: Delano posts a "follow" activity to his server with an object of Beth

<cwebber2> explicit side-effect in the spec

elf-pavlik: what side effects does this have? it's a delivery mechanism and also changing the collection

Tsyesika: it's an explicit effect
... this is acitivtypump specific

<cwebber2> +q

Tsyesika: the server needs to know the "inbox" endpoint for beth, so it can go discover the endpoints

cwebber2: btw some of this has changed from the pump API to activitypump at the request of the group, including the jsonld embedded in the HTML
... one of the options we discussde was whether we should embed jsonld into the html, but there are other options, we could embed microformats or rdfa into the document
... so we have not actually made decisions on this
... were previously using webfinger but the group decided not tu ose webfinger

Tsyesika: so this is still an open issue for doing the URL discovery
... so now you can make a post to their inbox

aaronpk: can you clarify the "public" id in the "to"

Tsyesika: this is a special URL that means the public collection

<cwebber2> well, and

<cwebber2> the target stuff is still in the editor's draft has to: cc: bcc:

<cwebber2> it hasn't dropped that yet

<cwebber2> for activitystreams 2

<cwebber2> but I think we're willing to move with the group

<cwebber2> it doesn't seem like it's gelled yet, even in the document

Tsyesika: pump.io uses primary and secondary audiences extensively, so i'm skeptical of getting rid of them

elf-pavlik: what's the difference with using "to" and specifying a secondary audience, vs just using target

Tsyesika: having a "to" of the public URL is essentially saying it's not to anyone, it's to everyone

<cwebber2> elf-pavlik: it's pubsubhubbub style

<cwebber2> it's not polling

<cwebber2> it's push

<cwebber2> you *can* pull

elf-pavlik: so why use the "to: inbox" why not just "target: my outbox"

Tsyesika: mainly because this is how all audience targeting works to avoid a special case for this

<cwebber2> elf-pavlik, public collections are a "special collection", there could be a different convention to have the stream

<cwebber2> but the convention is currently deliver to collections or users

bblfish: so the problem is in this case, the "id" is not derefencable so the code needs to special-case this all the time

Tsyesika: that's true
... okay now this is delano looking at his inbox, he sees the post made by beth of the image, and presumably more activities below
... unfollowing someone, they make another acitivty to their outbox, delano unfollowing beth
... the object is the person, send to beth and cc the public URL

<cwebber2> wseltzer: btw the call quality is much better now

Tsyesika: there is a suggestion for using the "undo" activity with the object of the activity you want to undo
... so in this case the user is removed from the followers collection

bblfish: in some ways there's a similarity between micropub, which is that this is also not restful

Tsyesika: we do specify an alternative way of doing this, you do a PUT to any object
... and has a side effect of generating the update activity

<cwebber2> we had PUT and DELETE and removed it on feedback

Tsyesika: in some reasearch evan did, most people were posting activities
... but we do make allowances for that in the specification

<cwebber2> evan looking into it was also partly prompted by tantek requesting possibly dropping it down to GET/POST only

Tsyesika: next story: https://github.com/w3c-social/activitypump/blob/master/userstories/reading-a-users-recent-posts.md
... 1. finding more content from an author

<cwebber2> activitypump is the socialwg iteration of the pump api ;)

<cwebber2> hey eprodrom !

<eprodrom> indeed

Tsyesika: looking at the inbox. this is where activitypump diverges from pump.io
... pumpio has a specific comment type, so when you're posting a reply you're posting a comment, which is like a note
... but in activitypump we don't have a comment type, you just post any object, and add an inReplyTo

<eprodrom> What

<eprodrom> That's not true

<tantek> interesting about no explicit comment type!

<eprodrom> Arnaud: I thought we were starting at 9:30 this morning again

<rhiaro_> eprodrom: can you clarify what's not true?

<hhalpin> evanpro - the Zakim code is: 26631

<Arnaud> we did

<eprodrom> pump.io API doesn't require a specific type

<eprodrom> hhalpin: thanks

<eprodrom> But OK

<cwebber2> eprodrom: http://www.timeanddate.com/worldclock/france/paris

<cwebber2> 10:22

<Arnaud> 9:30 was 1h ago

<eprodrom> Ah great

<eprodrom> My bad

Tsyesika: I apologize to evan if I made a mistake

<hhalpin> ok, regardless ActivityPump does have quite a few differences - evanpro, you may want to list them.

<hhalpin> In particular, re dependencies on the rest of the "Ostatus" stack

<eprodrom> Really?

<AnnB> Tseysika invites eprodrom to clarify

<eprodrom> Which, about the comment type?

<hhalpin> and clarify at some point what you think is crucial to keep and what dependencies you could live without. For example, didn't Google stop producing webfinger?

Tsyesika: you can if you wish to a GET on the user's outbox to see the activities they've done which is what's in this example

<cwebber2> eprodrom: what are you objecting to?

<cwebber2> that's where you should comment :)

<eprodrom> Will do

<AnnB> dang time zones!

Tsyesika: those are the user stories we got done last night, hopefully that gives you an idea

<cwebber2> Tsyesika++

Arnaud: are there any more questions?

<Loqi> Tsyesika has 9 karma

Arnaud: it seems that access control is a big difference

<elf-pavlik> Arnaud: looks like IndieWeb doesn't have ACL - looking at ActivityPump approach

<elf-pavlik> aaronpk: we experiment with with it and it may work similar to ActivityPump

<elf-pavlik> aaronpk: sending private not has some experiments but we still work on it

<elf-pavlik> elf-pavlik: public content seems focus so far in IndieWeb

<cwebber2> elf-pavlik: it's not using pubsubhubbub

<cwebber2> it's push-style

<aaronpk> pubsubhubbub is push-style, not sure what you mean

<cwebber2> aaronpk, right, I meant that it's push-style *like* pubsubhubbub, but it isn't *using* pubsubhubbib, sorry

<cwebber2> aaronpk, that was the clarification I meant

<aaronpk> (cool thanks)

bblfish: can you describe posting a photo

Tsyesika: you submit the file with the image content type, you get back the image ID
... then you can submit an activity with the photo object

<elf-pavlik> https://github.com/w3c-social/social-vocab/tree/master/activity/Follow Tsyesika can you please put it on a screen?

Tsyesika: i'm not thrilled about having several requests, I like how indieweb did it where you submit just one request with all the metadata you want
... we don't have any provisions right now for specifying a title when uploading the photo right now, so you have to do it in multiple requests

hhalpin_: quick note on the ACL point, I thought we had some stories about access control, but maybe not ones that we all agreed on had it
... so it would be great to get it working, but if we can't even get public working then we shouldn't do access control
... So in terms of activiitypump, it's nice that it's the one that's closest that maps to AS2.0
... if you're looking to converge with the indieweb approach, what is your take on the form encoding

Tsyesika: there's lots of nested stuff, but they get around it by posting stuff individually and referencing it by ID
... that'd work, but i'm not huge on making lots of requests
... i'm not necessarily against form encoding, but JSON has its merits, and especially JSONLD given its extensibility

<eprodrom> I have the answer, call on me

eprodrom: it's entirely possible, we had a mechanism in pump.io to include the image in the json encoded upload
... it's less popular because you have to do some encoding in the JSON upload, so people like the double post more often

<hhalpin_> I'm trying to map the "big" differences and see where we can get consensus on the larger whole.

eprodrom: i'd also point out that the double-post mechanism comes from the atompub protocol
... there is a mechanism in pump.io that didn't make it into activitypump, to encode a binary object in JSON, so if it's needed we can pull it over
... the other option is the double post mechanism

<elf-pavlik> https://github.com/w3c-social/social-vocab/tree/master/activity/Follow

<Zakim> elf-pavlik, you wanted to discuss sidefects

<cwebber2> elf-pavlik: it could be viewed in an RDF type graph as well that's probably true

<cwebber2> but

<cwebber2> what happens if you follow, unfollow, follow?

elf-pavlik: posting the as:follow activity has the side effect of adding the :follows edge

<hhalpin_> Arnaud, you may want to mention the IBM testing effort for ActivityStreams about now

<eprodrom> elf-pavlik: is the point that we'd have to test the behaviour?

elf-pavlik: you could make an automated test

Tsyesika: when you submit a folow activity, two things happen. The activity is federated to the audience, and the user is added to the followers collection
... so in the future, when you post to the followers collection as the audience, it will also federate to the new person

<hhalpin_> What is difficult about testing the side-effects (i.e. input->outputs)?

eprodrom: i think elf's point is that we don't have all those side effects listed out under the follow activity
... we should probably do that for each of these activities

<hhalpin_> +1 be clearer about the input/outputs but bugs will be worked out in test-suite

<eprodrom> "The Follow activity is used to subscribe to the activities of another user. Once the user has followed a user, activities shared with the Follows of that user SHOULD be added to the actors's inbox."

<cwebber2> http://w3c-social.github.io/activitypump/#activities

<elf-pavlik> data visualisation: https://github.com/w3c-social/social-vocab/tree/master/container/DirectContainer

bblfish: LDP also doesn't know how to do multiple files in one go

<cwebber2> multiple files is an interesting motivation for the file endpoint

<cwebber2> I hadn't realized that bit

bblfish: couldn't activitypump also use multipart uploads?

Arnaud: currently LDP1.0 spec doesn't talk about how to optimize this kind of operation, you have to deal with every resource independently
... there have been discussions about how to optimize the traffic
... there was some ealier draft that allowed it, there were questions about the details, so we took it out, now it's on the wishlist
... we just discussed the priority items for LDP, it was selected to allow that for the read, but not for the write
... it's not clear that the next version will allow to post multiple things inthe same operation

timbl: we could take input from here

<elf-pavlik> timbl++

<sandro> LDP WishList http://www.w3.org/2012/ldp/wiki/LDPNext

Arnaud: people are welcome to express their opinion here whether that's a priority

<Loqi> timbl has 3 karma

<elf-pavlik> aaronpk: i want to talk about Harry's question about convergence of APIs

aaronpk: I wanted to talk about question of converging apis

.. Bigger difference than form encoding

<bblfish> yes @sandro but there is also the list of 6 items that are being proposed for LDP next charter. that is more important

... In activitypump you're always creating an activity that references an object, but in micropub you only create an object and no explict activity

... trying to make those match up is more than dealing with nested objects

<cwebber2> aaronpk, I think you are right on that analysis

<elf-pavlik> http://rhiaro.co.uk/2015/04/post-and-activity-types

... it would take something like making micropub create activities vs objects, or having the activitypump api create the activities as a side effect of the object, rather than explicitly creating activities

<sandro> bblfish, sure, it's all up to there ACTUALLY being a sufficient community to do this.

harry: do developers find it easier to work with activities or objects directly?

aaronpk: from what I've seen creating objects directly has been extremely straightfoward

... but i haven't talked to a lot of people who are creating activitystreams posts

Tsyesika: a matter of personal preference

... activities are subject verb object type things

... like Tsyesika posts Image

<bblfish> yes, indeed but there should be a list of approved stories, so that those who are do not see their story in the wishlist, can at least drum up support :-) Ie. we need a diff

... activities very much how yo'd construct a sentence

... It's not too difficult for developers to work with activities. Just personal preference, one isn't easier or harder

<bblfish> oops

<eprodrom> Hey, the conference bridge is a mess

<eprodrom> Am I the only one who can't hear anything, cwebber2 ?

<bblfish> yes, indeed but there should be a list of approved LDP next desires, so that those who are do not see their desire in the LDP next, can at least drum up support :-) Ie. we need a diff

<cwebber2> eprodrom: it's been the hard the whole time, believe it or not it's better than it was ;\

Arnaud: aaron's point is that the significat difference between the two approaches is activities are implied and maybe reconstructed if you need to, whereas here they're explicitly stated and created as independant resources

<eprodrom> Oh

<eprodrom> Hi

<eprodrom> Developers overwhelmingly prefer the activity style

<elf-pavlik> eprodrom, we can't hear you

<eprodrom> I know, because your phone is all messed up

<cwebber2> eprodrom: they can hear fine though

<cwebber2> we just can't hear them

<eprodrom> We had about an OOM difference between object-style and activity-stle

<cwebber2> ;)

<kaepora> (Sorry I'm late: I'd like to repeat my offer to have a "crypto Q&A session" today so I can help as the invited observer who works in crypto)

eprodrom: with pump.io we have an order of magnitude difference between people doing operations on activities vs creating objects directly

<akuckartz> kaepora++

<Loqi> kaepora has 1 karma

<eprodrom> I can't hear, have to wait for the scribe

<cwebber2> eprodrom, the question was:

<eprodrom> Is there a way to fix the phone there?

<sandro> we can try hanging up and dialing again, I guess

<Arnaud> we didn't know it was broken!

<sandro> you're not hearing anything?

<bblfish> we need a coffee break to fix it. What is the problem you are experienceing @eprodrom ?

<cwebber2> eprodrom, could you clarify, was it that you had an experience with an overwhelming number of developers having preference

sandro: i think you were saying you tried both approaches and people preferred one?

<cwebber2> between activities and objects

<cwebber2> let eprodrom respond before we do that dance

<eprodrom> Yes, from pump.io logs

<sandro> cwebber2, it was working earlier, right? did it stop at some point?

<cwebber2> yes much better

<cwebber2> sandro: it has been bad the whole time

<cwebber2> sandro: but it was even worse earlier

<hhalpin_> we could always switch to talky.io

<cwebber2> I agree it's not a connection

<cwebber2> now it's much clearer

<sandro> it's just a long room, so some people aren't near the speakerphone.

<cwebber2> anyway, maybe eprodrom should be able to reply to that point before we do any connect/disconnect dance?

<cwebber2> +q

<cwebber2> -q

<rhiaro_> eprodrom: did you mean people use posting of activities more than PUT and DELETE on objects?

eprodrom: yes, that's what I meant

<cwebber2> eprodrom: your turn to speak

<cwebber2> are you muted?

<eprodrom> Yes

<eprodrom> One sec

<Arnaud> eprodrom, can you please expand a bit on what you meant

<eprodrom> Let's just go to break, I'm sorry

<sandro> is there something you want us to do during the break?

<cwebber2> whoooo

eprodrom: yeah we did a big log scan based on a question from tantek. we had about 10x more people using activities endpoints posting update and delete activities ranther than PUT and DELETE on objects

<rhiaro_> eprodrom: that was via Tsyesika btw

eprodrom: i'd like to talk about differences between activitypump and pump.io api
... there's a notify method, pump.io uses a regular webhooks mechanism, the other is activitypump requires https IDs for objects and pump.io allows any ID for objects
... the requiement for https IDs came in from activitypump
... i'm not crazy about it

Tsyesika: there's an issue open about both things, most of those are things left from how oshepherd wanted it, and I just didn't change it

<hhalpin_> so maybe dropping those HTTP IDs might be possible.

Tsyesika: i'm more than open to having less stringent requirement for IDs, I don't think requiring TLS on URIs is necessary

<hhalpin_> that would probably make people happier re convergence

<rhiaro_> people using activities endpoint over PUT on objects could be a preference for endpoints over restful, not necessarily activities over objects (cc Tsyesika, eprodrom, cwebber2)

Tsyesika: for the most part we're open to change

<Zakim> elf-pavlik, you wanted to discuss shortly lon side effects in MicroPub, ActivityPump and LDP

<elf-pavlik> https://www.w3.org/wiki/Socialwg/Social_API/User_stories#User_posts_a_file

<elf-pavlik> https://www.w3.org/wiki/Socialwg/MediaObject

elf-pavlik: activitypump seems heavy on side effects, LDP seems light on side effects
... the user posts a file is a great story to demonstrate side effects
... if we all compare this story we can talk more about the side effects

Arnaud: i thinkwe can defer that discussion to later
... the plan is next to talk about the similar stories with SoLID, the rest of the day is about talking about how they compare

hhalpin_: we are at inria, the world top center for TLS and web security stuff...
... i'm going to talk with the researchers here, if people wanted to do a brief security session, maybe people would be interested

<KevinMarks> hm, the dev pref for activities seen on pump could be because those are theire esamples

<cwebber2> totally dropping out

<elf-pavlik> +1 TLS session

<cwebber2> the call, I mean :)

<KevinMarks> PUT rather than POST?

<hhalpin_> should we do a crypto or TLS session?

<hhalpin_> I'll ask Karthik what his schedule is, but Nadim could also do it.

Arnaud: let's take a break for now, 10-15 minutes then look at SoLiD

<KevinMarks> PUT is a pain to do; POST is a form, hence micropub

<AnnB> bye, cwebber2 ... if you're going

<cwebber2> AnnB: oh I'm not leaving

<eprodrom> Tsyesika: I just found out that SUBSCRIBE/NOTIFY is an existing model in WebDAV

<eprodrom> https://msdn.microsoft.com/en-us/library/aa142938%28v=exchg.65%29.aspx

<cwebber2> I meant, the call was dropping in and out of my ability to hear :)

<eprodrom> https://msdn.microsoft.com/en-us/library/aa143117%28v=exchg.65%29.aspx

<AnnB> ah yes .. they're rebooting phone I think

<eprodrom> Tsyesika: also, great job!

<cwebber2> yes indeed

<Tsyesika> eprodrom: thanks! sorry about the few mistakes i made >.<

<AnnB> yes, Tsyesika++

<cwebber2> Tsyesika, kick ass work :)

<cwebber2> Tsyesika++

<Loqi> Tsyesika has 10 karma

<eprodrom> Tsyesika: yes, sorry about my outburst

<eprodrom> With pump.io, the "comment" type isn't required for a response

<Tsyesika> thanks for clarifying

<eprodrom> Any in-reply-to response will work

<AnnB> pretty mild, if that was an outburst!

<cwebber2> :)

<cwebber2> anyway, I knew Tsyesika was the right person to present on the subject

<eprodrom> However, I think the Web UI will barf if it sees something besides a comment there

<eprodrom> Yes, fantastic

<cwebber2> Tsyesika: I think you did a clearer job of presenting on the spec than I would have!

<eprodrom> Did you ever hear back from Owen Shephard?

<cwebber2> ok, now that we're at a bredak

<cwebber2> I can finally get coffee

<cwebber2> finallyyyyyyy

<oshepherd> eprodrom: *sticks nose in*

<AnnB> go for it!

<eprodrom> HEY

<cwebber2> ohai oshepherd :)

<eprodrom> Also, misspelled

<eprodrom> Your last name

<eprodrom> Hooray that you are here oshepherd

<oshepherd> I have been suuuuper busy

<sandro> anyone on the phone

<oshepherd> I commented a couple of weeks back on verb vs object orientation... My conclusion was that the only difference here between indieweb and ActivityStreams *in practice* was the "post"/"share" verbs which IMO are very contentless (and I'd actually prefer ActivityStreams without them, because in practice they're - specifically the post verb - a huge source of problems in pump.io

<oshepherd> Specifically the problem is that you really want the audience attached to the object, but it ends up attached to the post

<oshepherd> Anyway, on the subject of mandatory TLS: I'll note that the both Google, Mozilla and I believe the W3C itself have announced an intent to deprecate HTTP (non-S)

<eprodrom> Understood

<eprodrom> I like a SHOULD but I'm less crazy about a MUST

<eprodrom> I also like Webfinger

<elf-pavlik> kaepora: https://www.tuxed.net/fkooman/blog/indiecert_nitrokey.html

<eprodrom> But I understand that the requirement for dereferenceable URIs makes that more complex

<oshepherd> I haven't had a chance to catch up with Tsyesika's changes, but I did keep Webfinger *just* for the use case of translating user@domain identities

<eprodrom> (We have to drag in the Webfinger spec)

<eprodrom> Oh, I think it's out now

<eprodrom> elf-pavlik: I find it funny that you talk about the update to the social graph as a "side effect"

<eprodrom> It seems like the primary intent of posting a "follow" activity

<oshepherd> Theres a whole lot of social platforms out there today using such identities - StatusNet, PumpIO, Diaspora, more traditional things like XMPP, even email. I don't think we can say "Sorry, you have to throw away all your user IDs" to them

<eprodrom> I see your point

<eprodrom> But I think there's something to be said for consistency too

<eprodrom> (I prefer keeping the Webfinger ID, btw)

<oshepherd> But I very much kept WebFinger use minimal - its' just "take an acct URI and translate it into the URI of an ActivityStreams profile document" - and if your IDs aren't in acct: form, you don't need to implement a server

<eprodrom> All of which is to say

<eprodrom> oshepherd++

<Loqi> oshepherd has 3 karma

<eprodrom> Tsyesika += 1,000,000

<eprodrom> Actually I guess in Python that'd be

<eprodrom> Tsyesika = Tsyesika + 1000000

<oshepherd> Python has +=

<eprodrom> Oh

<eprodrom> Great!

<oshepherd> Doesn't have ++ though, unless my brain has gone fuzzy

<eprodrom> I usually assume that if a particular syntax element is convenient Python prudishly disallows it

<eprodrom> B-)

<oshepherd> I spend most of my time coding in SystemVerilog these days which is the mother of not-at-all convinient

<oshepherd> (No, SystemVerilog, nobody wanted their function's member variables to default static. But that's enough ranting about SystemVerilog :-))

<eprodrom> Wow

<eprodrom> OK, I will pipe down then

<eprodrom> Tsyesika, it looks like AS2.0 doesn't even have a "comment" type

<eprodrom> Which is probably good

<eprodrom> I've never been a big fan

<Tsyesika> eprodrom: yeah we use "Note" type as an example of what i'd use a "comment" in pump.io for

<oshepherd> It's basically just a "note"

<rhiaro_> scribenick: rhiaro

<aaronpk> scribenick: rhiaro_

Arnaud: we have all afternoon, if we don't get through before lunch we can go on after
... can people on the phone hear?

<cwebber2> I can hear

<Tsyesika> oshepherd: i did want you to look at #15 and #19 on https://github.com/w3c-social/activitypump/issues

<Tsyesika> oshepherd: not now but sometime

deiu: will start with most basic example, create edit and delete a note
... then henry's going to go over two more complex examples, profile editing and access control stuff
... So SoLiD uses LDP to create new resources and manage resources

<sandro> https://github.com/linkeddata/SoLiD/blob/master/README.md#brief-example-of-solid-in-action

deiu: This makes it really easy for people who are used to a restful way of doing things
... compared to previous examples, we're not using an endpoint to post new data, but creating data inside a container that is used to store similar types of resources
... in this case, a notes container

<oshepherd> Tsyesika: Using the NOTIFY element is supremely elegant. It's also quite likely to be a supreme pain in the ass, so I'd say go ahead and replace it with POST.

deiu: So we can see here our examples use curl
... just to give you an impression of how simple they are
... What we're doing is sending a post request with slug header, and data containing actual note. Uses activitystreams terms to describe note
... [and is turtle]
... could be json-ld

<oshepherd> Tsyesika, as for HTTPS, maybe table this one for later. By the time any spec becomes a REC, I expect Lets Encrypt should make TLS certs trivially available

<eprodrom> Could you speak up, please, deiu ?

deiu: use AS2.0 vocab

sandro: we haven't implmeented anything that uses that

deiu: we don't have an app that consumes AS2.0 data
... the point is to demonstrate how you create and modify data

timbl: you can do it with a client without the server knowing anything

deiu: What the server returns is a Location header which has the full URI of the new resource
... Second step is to correct/complete the note that was sent before
... Client needs to update existing resource with the new data
... SoLiD has two ways of doing this
... can do a PUT to replace whole resource
... uses URI of new resource, that you get back in the Location header

<Tsyesika> oshepherd: might be good to write that on the issue just so evan can respond, i am not against lowering the requirements but i'm also not really bothered by it either but it seems evan is

deiu: Second way of doing is to send an HTTP PATCH with a SPARQL UPDATE

<eprodrom> Yes

<eprodrom> I am

deiu: in which you modify only the bit of information you want to change

<AnnB> phone people ... are you still having trouble hearing?

<eprodrom> Yes, it's just fading in and out

deiu: We should probably add PATCH but it's not relevant to this group

<eprodrom> I think the speaker needs to be louder or closer to the phone

<aaronpk> he's as close as he can get

sandro: PATCH is subject to conneg. The one here is implemented, but there's a w3c rec for a different patch format

<eprodrom> OK, thanks

<elf-pavlik> http://www.w3.org/TR/ldpatch/

deiu: we do support json patches
... if you have json-ld file you could use that
... final step is user decides to delete note
... HTTP operation on the resource itself (DELETE)

eprodrom: social software often when you're posting a note, you would send it somewhere, like the inbox of followers or mentions inbox of person mentioned
... I understand this wouldn't be possible?
... So side effect wouldn't happen server side, has to happen client side

deiu: yes, everything happens in the client. Client is charged to send notification to someone's inbox
... or you could have additional app-specific service which listens to changes on containers
... then based on changes on containers like new resource created, could trigger app-specific processes

melvster: triggers websocket

eprodrom: that's interesting

<elf-pavlik> ACTION: pelf create comparison of side effects approach in MicroPub, ActivityPump and SoLiD [recorded in [[1]|http://www.w3.org/2015/05/05-social-irc]]]

<trackbot> Created ACTION-61 - Create comparison of side effects approach in micropub, activitypump and solid [on Pavlik elf - due 2015-05-12].

eprodrom: twitter members have millions or tens of millions of follows, would not be scaleable to have client distribute note to millinos of inboxes
... starts becoming difficult for client
... and if two different clients do it differently you don't have a very consisten social experience
... so if there is a way to have a consistant side effect that provides these sorts of features in ldp that would be interesting
... access control too

deiu: we have access control
... SoLiD does implement websockets
... has a websocket interface for all it's resources
... you could have a service which listens on a websocket which has subscribed to that container, which can process all the data that gets into the container

<cwebber2> huh, that's interesting

timbl: which works for hundreds of thousands of people

eprodrom: if you come check yoru inbox in the morning and want to see all the stuff that happened since yesterday, has to be some kind of application process, or you can leave a websocket open all night
... so websocket interesting for online updates, but not distirbution

deiu: distribution happens by a service, like a pubsub service
... that listens to data and upates all its subscribers

Arnaud: more background on ldp

<elf-pavlik> ACTION: pelf document possible danger of malicious apps when moving more responsibilities to clients [recorded in [[2]|http://www.w3.org/2015/05/05-social-irc]]]

<trackbot> Created ACTION-62 - Document possible danger of malicious apps when moving more responsibilities to clients [on Pavlik elf - due 2015-05-12].

Arnaud: there are different use cases. LDP spec defines generic protocol to create and update and find resources
... but there are different types of servers that can implement LDP
... there is what we refer to as (??) applications
... no specific application semantic associated
... generic datastore
... you send bits, they store, you ask and they return
... never any side effects
... Other peopel use LDP with very application specific servers
... for example, IBM uses LDP in the context of application lifecycle management
... LDP is a thin layer put on the top of legacy software
... in this case when you create a resource using LDP you create something with very specific semantics, and has application specific side effects
... possible to imagine in this case you could have an application specific server, with side effects like distribution and notifications and things like that

<Zakim> aaronpk, you wanted to ask about "slug"

aaronpk: about slug - is that meant to be a unique slug per note, or a namespace where multiple things go?

<eprodrom> rhiaro_: thanks for scribing so well

deiu: a hint on how you want URI to end up looking
... was name, not namepsace
... suggested name
... server could ignore it

Arnaud: that's not specific to LDP, there's an RFC on slug

aaronpk: Ok. Other thing - you do or do not have implementations consuming the data?

deiu: I meant about activity streams vocab
... we don't have an implementation that consumes AS
... things created so far don't use AS

sandro: CIMBA uses SIOC

<Zakim> elf-pavlik, you wanted to discuss request for Social WG oriented view on SoLid

<elf-pavlik> action-61

<trackbot> action-61 -- Pavlik elf to Create comparison of side effects approach in micropub, activitypump and solid -- due 2015-05-12 -- OPEN

<trackbot> http://www.w3.org/Social/track/actions/61

elf-pavlik: for the side-effects I created action-61
... I don't think it's enough to just have this in minutes
... we should document on wiki

<elf-pavlik> https://github.com/linkeddata/SoLiD/issues/18

elf-pavlik: Also I'm going to request on SoLiD repo that we can have a social web perspect
... ive
... eg. using json-ld first instead of turtle, etc
... to make it easier for group
... whoever wants to work on it with me, can help

timbl: do you think making it a live switchable document, switching example format between json-ld and turtle is good? Or document rewritten?

elf-pavlik: I think some things like with sparql updates, some people won't even want to go there

<eprodrom> elf-pavlik: That's true

deiu: sparql and ldp patch or whatever else have been added as alternatives
... in addition to LDP http requests

<eprodrom> My eyes just skip over those options

deiu: we should work together

elf-pavlik: make it clear we don't HAVE to use these

<elf-pavlik> 11:36eprodrom My eyes just skip over those options

<AnnB> what do you mean, eprodrom, that your "eyes skip over those options"?

bblfish: it would be extremely useful for LDP or this group, to have some way for any resource to be able to say I want to subscribe to this resource so you can say you want to see any changes on a document. Could be really generic
... would work like activitystreams, could poitn to another collection somewhere else

<eprodrom> When there's a section of SoLiD like, "Or, you could do a SPARQL query like this..."

bblfish: the resource itself on the server could post notification changes

<eprodrom> AnnB: ^^^^

bblfish: we could solve the problem mentioned on the phone

<aaronpk> eprodrom: AnnB: same with me

Arnaud: there are discussions about this in LDPNext about being able to keep track of changes to resources and be notfied
... you can have an optimal way of knowing what has changed

<AnnB> does that mean it's not useful to you, or it's not actually functioninng, or ...??

Arnaud: instead of having to fetch the whole resource and figure it out
... you can use patch format to tell you what has changed. Possible in future of LDP

<Zakim> sandro, you wanted to say I'd like webmention to be part of vanilla LDP

<eprodrom> AnnB: It's not useful to me, and mentioning it in the spec is less helpful

sandro: what would solve that is if webmention were standardise and LDP incorporate that
... assuming you can have massive webmention servers. Offloads from client and puts in normal server infrastructure

<KevinMarks> PUT and PATCH are retro von Neumann worldviews

claudio: from my commercial point of view, most of the use cases are around personas rather than topics

<KevinMarks> POST is more general

claudio: but we have uses cases where it's important to people to stream content, to interact over topics instead of among each other

<AnnB> so eprodrom, is that specific to rdf and sparql, or all of the linked data stuff?

claudio: If we have a streaming event like a movie, we are really interested in seeing what people are thinking about a topic

<eprodrom> AnnB: it's actually more editorial about the document

<AnnB> aha, thanks

claudio: we are forseeing technologies for adapting streaming content to people's mood etc. So critical to happen realtime. I wonder if these technical solutions would cover it

<eprodrom> There's one clear and simple way to get a task done, then a few other options that are less clear and less simple

<KevinMarks> movie's aren't streaming

claudio: As far as I understand most silos are consumer oriented. In twitter you can provide a topic and see how people react to that
... We are using webRTC, there's a lot to do, to provide personalised video streams
... so we need to know what people are thinking

sandro: hashtags?

<AnnB> altho I still don't truly understand the nuance of your comment

<KevinMarks> 2-way is streaming; movies are downloads

claudio: yes but we don't want to rely on twitter
... intreesting example with virtual product placement, or virtual notification of live streaming events
... We are not sure we can model it with most of these decentralised solutions

<eprodrom> claudio: there are two options

<cwebber2> +q

<KevinMarks> hashtags are not bound to twitter

<AnnB> fyi, Claudio is from Telecom Italia

<KevinMarks> they span multiple models

sandro: out of scope for this group

<eprodrom> ben_thatmustbeme: for me too

Arnaud: do we have user stories that get close to this?

<cwebber2> ben_thatmustbeme: yeah the call quality is not good

bblfish: we have a bug database that is content oriented
... or one for a product
... interaction on an object not on a [person] community comes around the object

sandro: hashtags are harder, they don't have identifiers

claudio: we are looking at things in Telecom Italia, in talks with netflix, they're using product placement for funding content
... this could be done on the fly
... adaptive advertisement
... customise content based on what people are saying in realtime
... this is feasible

<aaronpk> yeah we really need external mics for the phone because the people on the ends of the table are super hard to hear

<eprodrom> ben_thatmustbeme, sorry

<bblfish> this is the user story I mentioned https://www.w3.org/wiki/Socialwg/Social_API/User_stories#Product_issue_reports

claudio: we rely on twitter for now because we don't have an open decentralised solution for this
... I understand may be out of socpe
... topics could be in the future

<cwebber2> ben_thatmustbeme, sorry, it's my client default to use :

<cwebber2> so I have to correct it constantly

sandro: we had a hashtags user stories, was -1 because it's too hard

<cwebber2> I figured the scribenick made it clear

<AnnB> (I called his attention to your comment, KevinMarks, about streaming vs download)

elf-pavlik: could observe if something is out of scope and check if something might block it in the future and flag it

<cwebber2> but I guess not

elf-pavlik: and we can do our best to take that into account

claudio: I wonder if taking it into account could make it easier if we decide we want to handle it

<cwebber2> I guess it doesn't, at least, when someone takes over for scribing

claudio: I understand standardising hashtags is not easy
... or impossible
... but could be valuable

<eprodrom_> Aha

bblfish: a company that did a bookmarking service, you could bookmark things and when you typed a word they would do a text analysis, then find dpbedia concepts and URIs that were related to concepts in the page
... it looks to the user like a hashtag, but behind is the semantics of dpbedia and URIs
... helps users avoid clashes

<eprodrom_> Are we still talking about the media monitoring?

timbl: there are some structured hashtags, some are totally random
... it would be fun though

<eprodrom_> Could we maybe get back to the social API agenda?

<KevinMarks> autocomplete is fine, estatign the tag the user assigned isn't

<eprodrom_> Arnaud, are we on-topic?

elf-pavlik: could have hashtag.cc like prefix.cc

<eprodrom_> I'd like to talk about SoLiD

ALERT everyone's wifi passcodes are expiring

stay tuned

eprodrom: can we go back to talking about SoLiD
... concerned that notifications like webmention might be useful, but in other ones there's a more complex effect in executing a social action
... eg a follow action would update the actor's following list
... and distribute follow action to several inboxes
... so I'm not sure this is just about notification
... there's a lot of updates that could happen
... again, it's all entirely possible to do these using polling
... you could poll every list of every social graph then add reverse pointers
... but much easier to get collection of people
... if we use SoLiD we're goign to have to put a lot of burden on the client which is unfair to the client and likely to generate a lot of errors
... or we're going to have to limit ourselves to very simple social interactions

bblfish: we have more examples

<timbl> One could use (coincidentally) a distributed hash table for coordinating people interested in hashtags. The problem is a bit like the NNTP newsgroup distribution problem, as newsgroup names and hashtags are both basically arbitrary short strings.

<elf-pavlik> action-61

<trackbot> action-61 -- Pavlik elf to Create comparison of side effects approach in micropub, activitypump and solid -- due 2015-05-12 -- OPEN

<trackbot> http://www.w3.org/Social/track/actions/61

<elf-pavlik> eprodrom_ let's work on documenting it together?

cwebber2: I'm curious what happens in terms of how much link rot impacts this system, especially if you end up having communication with someone else and their whole site goes down? How does that affect your local record of your interaction with them? And also resolving information about that?
... curious about what ends up happening when somebody else's server goes down

<eprodrom_> timbl, you could also have one or more aggregation servers

deiu: how is this specific to solid? will affect any decentralised service?

<KevinMarks> hashtags converge because language converges

cwebber2: if my mail server goes down you can't send me email. You still have access to all the email you have from me
... and contact metadata
... I'm not making a comment, this is a real question

<sandro> We do have hastags: https://www.w3.org/wiki/Socialwg/Social_API/User_stories#Search_content_with_hashtags

<sandro> As Evan said: -1. I think search is probably difficult to do for this API. Maybe a separate API? --Evan Prodromou (talk) 16:02, 18 February 2015 (UTC)

sandro: we don't address that yet, the answer is to use caching proxies or archiving services where I access your site through something that keeps a copy
... we need that for performance reasons too

<KevinMarks> to put it another way, hashtags works precisely because they don't have namespaces; thus forcing convergence

deiu: in a decentralised system, there are two ways to shuffle information around
... you base it on poll or push
... either you push notifications to people directly to their own servers
... or you wait for them to poll your feed/outbox of notifications and everyone gets theirs when they want

bblfish: interesting compatibility with AS2
... you could have feed of activities which you fill in whenever an action happens on the LDP server
... if a client misses a poll request they can go back to the feed and find all the changes
... this might be where this is going

timbl: you can convert between the two

<cwebber2> thx sandro, deiu

timbl: when you know the state of some resource you can accumulate the differences
... if you have a series of update messages you can generate the results

Arnaud: eprodrom, isn't that true for all other solutions too?
... if aaron's website is down I can't access any content?

<cwebber2> I think you mean me, not eprodrom_ :)

Arnaud: same with pumpio and activitypump
... Valid question, but why make it sound like it's specific to SoLiD?
... sorry I meant cwebber2

cwebber2: curious because I imagine (??) sparql something ..
... you end up storing copies of communication
... not sure if you do sparql queries across multiple sites
... I just don't have experience with this type of infrastructure

<ben_thatmustbeme> Arnaud, in microformats its assumed that data is copied and stored, not constantly pulled

cwebber2: I think there are issues when a node goes down and someone can't access

<hhalpin> An invited observer, Francesca Musiani, who is studying decentralized networking and internet governance as a sociologist at CNRS, has just joined us.

cwebber2: anyway, not trying to challenge this, just to see if this is something that SoLiD has

<Zakim> elf-pavlik, you wanted to discuss capturing ACTIONs

elf-pavlik: quick comment. I see need that we capture more actions and put thing son wiki page as we explore things
... every meeting every week we stumble on the same things from different directions
... every time there is a problem make an action or put it on the wiki
... it gets lost in the minutes
... indiewebcamp has a good approach, we can take inspiration from that
... to build up common understanding of each implementation

deiu: can we make it an open issue? [caching] and think about it later? It affects every proposal

elf-pavlik: someone take action to document issue

sandro: or just raise issue

deiu: please raise issue

eprodrom: I think the reason chris brought it up is that SoLiD is putting a lot of the burden onto the client to make sure that the state of the world is maintained
... I know you're trying to concentrate on simple examples

<sandro> issue: do we need the overall system to be robust even when nodes fail?

<trackbot> Created ISSUE-39 - Do we need the overall system to be robust even when nodes fail?. Please complete additional details at <http://www.w3.org/Social/track/issues/39/edit>.

eprodrom: but I'm more interested in ones that have more complex interactions like follow

<Loqi> Aaronpk made 1 edit to Socialwg/Social API/User stories https://www.w3.org/wiki/index.php?diff=84005&oldid=83430

eprodrom: would generate a follow activity in my outbox, generate multiple follow activities in multiple inboxes, update my follows list and would update someone else's folllowers list
... if any one of those fails, then the state of the world is out of sync
... in pump.io each server is responsible for processing those actions Only one message is transmitted between servers
... if evan on one server follows arnaud on another server the only notification that goes from one to the other is the activity notification
... the server doesn't try to write to arnaud's collection from even's server
... that means just re-sending an activity is much easier
... server's responsibility, so much easier and more reliable
... can do retries
... not up the client

Arnaud: solid have more walkthroughs

deiu: SoLiD started as a general platform not social, but we are interested in managing notifications
... We want any app to have a way to notify apps and other servers about changes
... So AS2 could help us do that
... which means we would have to implement some of this logic in the server

<eprodrom_> That's great

sandro: different answer

<Zakim> sandro, you wanted to answer eprodrom_ re consistency

sandro: about 20 minutes ago henry mentioned idea of generic website

<cwebber2> so move the side effect / notification stuff off to activitystreams, and the actual store of things on RDF / linked data?

sandro: we haven't implememented this yet, this is speculative

<cwebber2> is that what you mean deiu ?

sandro: If I follow someone we change the link to say I follow them, then there's data propagation that doesn't care about the semantics of what happened. All changes are all just data changes
... haven't standardised that yet, but lots of ways to do it

timbl: could be something like thermometer has just taken new temperature reading

sandro: we want this to work for long tail of multi user applications, social is just 1%
... doesn't necessarily mean anything to anyone in this group, but this is the background about why we're designing like this

<Zakim> elf-pavlik, you wanted to discuss running same logic on client and server (more general clear documentation of concerns / responsibilities )

elf-pavlik: to give our collaboration more structure. We can't say easier/harder/worse/better - it's subjective. We should document possibilities and constraints so everyone knows the options
... We need clear way to talk about rendering, content editing, notifications, we need clear vocabulary for this
... Because responsibilities can be handled elsewhere
... Don't make constraints based only on personal use cases, but document these constraints

AnnB: enterprise interest is more about workflow management
... than social
... seems that the linked data stuff which reflects more data changes, like some travel approval comes through or some supply chain change
... in Boeing we transfer every ten minutes as much data as in the library of congress
... so the general data stuff is important to me/Boeing

<hhalpin> ?

sandro: the other proposals can handle data flowing as well

<hhalpin> Are we done with SoLID stories?

<eprodrom_> hhalpin: I think I keep interrupting

<hhalpin> Or can we move comparing SoLID to ActivityPump?

<eprodrom_> Maybe we should let deiu finish

bblfish: there's no distinction between client and server. servers can speak to servers to make these updates too, could be in the background
... then we rely on REST for getting and caching resources
... all the infrastructure of the web is there for us
... no duplication of data because all data is at the URI that names it
... so what's missing is for updates to be sent when the content changes before the cache expiry date
... to say please refresh cache. At architectural level that's what missing

<elf-pavlik> cache includes browser cache, social backend cache etc.

<AnnB> to expand my point, we are interested in the "social" components, as well as the workflow management -- and we see relationship between the two

Arnaud: break for lunch, continue with user stories after lunch

hhalpin: some AC people have to leave at like 3?

sandro: at 5, when the meeting is over

AnnB: we're going straight from here

<eprodrom_> rhiaro_: actually the schedule stuff is very helpful

<eprodrom_> For those of us on the phone

<eprodrom_> Since it's mostly inaudible

<eprodrom_> rhiaro_: thanks

<eprodrom_> So breaking for lunch now?

hhalpin: who wants a TLS session after SoLiD

<eprodrom_> Thank you

<eprodrom_> Sorry to be so needy :)

hhalpin: if people want to fit that in, we're in INRIA so we could have a TLS session
... but it's out of scope for group

AnnB: let's not get distracted

Arnaud: we should go through our agenda
... two more stories for SoLiD
... general discussion
... comparison
... once we've seen three different proposals, see what the differences are
... then there are demos

melvster has short demos, for more generic use cases. deiu has a specific demo

AnnB: TLS thing feels too much distraction
... Didn't know it came up

Arnaud: proposal is that once we're done with agenda, those interested can have security discussion with INRIA

<elf-pavlik> +1 TLS after AC participants leave

<cwebber2> hey also

Arnaud: *now* breaking for lunch

<cwebber2> rhiaro++ for great scribing :)

<Loqi> rhiaro has 74 karma

<aaronpk> rhiaro++

<eprodrom_> Thanks for scribing rhiaro_

<Loqi> rhiaro has 75 karma

<eprodrom_> rhiaro++

<cwebber2> rhiaro is a karma accumulator

<Loqi> rhiaro has 76 karma

<rhiaro> Lunch 1 hour

<rhiaro> back at quarter past

<rhiaro> For anyone not physically present, we haven't made it back from lunch yet

<cwebber2> rhiaro: ok thx

<eprodrom_> rhiaro: thanks

<eprodrom_> I like that phrasing

<eprodrom_> It makes it sound like we're visitors from the spirit realm

<ben_thatmustbeme> Zkim, mute me

<eprodrom> Are we live again?

<ben_thatmustbeme> i hear nothing

<ben_thatmustbeme> i just jumped on to see

<tantek> greetings - administrivia request: I'd like to cancel next week's telcon (and suggest adopting a culture of skipping the week after a f2f)

<ben_thatmustbeme> eprodrom, there is talking again

<tantek> Arnaud, eprodrom, hhalpin ^^^

<Arnaud> hola

<Arnaud> tantek: what's the rationale for that?

<rhiaro> People are just drifting back in

<rhiaro> most people not back yet

<tantek> Arnaud: it's a request, and typical in many WGs. Allows for more time for post-f2f async follow-ups (which there tend to be more of) before the next telcon.

<cwebber2> I didn't hear anything, but I am redialing

<cwebber2> could have been my connection

<tantek> Also good to acknowledge that sometimes a f2f can be tiring and giving people a week to "recover" is good too.

<Arnaud> I'm open to it but not in favor of making it a rule

<tantek> I don't think it's a rule in any WG - more of a custom.

<tantek> So I'm proposing it as a one-off for next week

<tantek> then we can get feedback from WG members about were they ok with it, appreciated it, or would have preferred having a telcon.

<Arnaud> "adopting a culture of skipping the week after a f2f" sounded like making it a rule/policy

<cwebber2> I can hear again

<tantek> Arnaud: the *and* was intended as a two part proposal

<Arnaud> ok

<tantek> I wanted to provide my longerterm intentions

<cwebber2> ben_thatmustbeme, no?

<cwebber2> arg

<ben_thatmustbeme> cwebber2 haha, :P

<cwebber2> (setq erc-pcomplete-nick-postfix ",")

<cwebber2> there we go

<eprodrom> Cool

<eprodrom> It's almost worse to hear the telecon at this point

<eprodrom> IMTS the audio

<eprodrom> Mostly getting rough impressions

<sandro> hm? How's the audio? There are multiple conversations in the room as we haven't started yet.

<eprodrom> Ah, right

<eprodrom> sandro, it's pretty bad right now

<eprodrom> That's great

<eprodrom> I'm sorry to be so demanding about the phone

<tantek> I am still in a separate meeting and cannot call in.

<eprodrom> It's a lot easier when someone is scribing

<Arnaud> fyi: we had lunch at a restaurant nearby that was pretty crowded and it took longer to get served than we would have liked

<Arnaud> people are still slowly coming back

<cwebber2> eprodrom, someone needs to scribe the ambient smalltalk! ;)

<eprodrom> No problem whatsoever

<tantek> Arnaud: PROPOSAL: Skip next week's telcon as being the week after a f2f.

<cwebber2> +1

<Arnaud> personally I think we still have issues on AS we could talk about on the telecon

<tantek> we will continue to do so, and I think they could wait til the next telcon

<cwebber2> I'm not against the telecon :) I just wouldn't mind the break!

<tantek> cwebber2: agreed. We could use the break after a f2f.

<sandro> scribe: sandro

<scribe> scribenick: sandro

<ben_thatmustbeme> Before we start do we want to bring up tantek's proposal?

which is, in a few words?

<Arnaud> I'd rather wait to see where we end up

<tantek> sandro, PROPOSAL: Skip next week's telcon as being the week after a f2f.

<tantek> Arnaud, is that a -1 or a 0?

<Arnaud> this is: later :)

tantek, I suggest we use it as an informal recap of the F2F, esp for people who didn't attend

<ben_thatmustbeme> tantek, i think thats a postpone vote

<cwebber2> informal recap could be ok

<eprodrom> Sorry to say, we're behind on our deliverables and I don't think it makes sense to take a week off

<aaronpk> https://github.com/linkeddata/SoLiD/blob/master/UserStories/UserProfileManagement.md

<tantek> I don't think that's a good use of sync time - recaps belong in summaries on a URL.

solid walkthrough: profile management

<Arnaud> I'm with evan

tantek, in my experience, these recaps are mostly discussion

<tantek> eprodrom, we're only "behind" because the dates set were unreasonable and without explicit methodology as to *how* they were going to be met.

<tantek> so such "we're behind" justification is a bit hollow

deiu: I'm showing my profile, using an app, which gathers the data from multiple sources, some of which are public and some are restricted-access.

<eprodrom> tantek, but that's what people who run late always say

<tantek> eprodrom: that's a tautology and false

<tantek> I stated from the beginning that the proposed schedules were unrealistic and should be dropped.

<eprodrom> Fair enough

deiu: I'm adding a phone number, and the apps asks which place I want to put it -- with different associated access control

<tantek> I don't think such top-down schedules are a good way to run or motivate a working group

<melvster> sorry

deiu: See how in the PUBLIC version of my profile, my phone numbers don't appear

<cwebber2> melvster, are you running mIRC on windows95? ;)

deiu: that is, when I'm not logged in

<melvster> misclick

<kaepora> No, you can't use a#b to scroll to a location in a JSON! I just checked! :P

deiu: the app pulls in the profile elements from different places

<cwebber2> I do wish I could watch this presentation... I suppose such things are the risks you take when you attend remotely tho :)

<elf-pavlik> kaepora++

<Loqi> kaepora has 2 karma

<eprodrom> cwebber2, you get what you pay for

deiu: (shows network trace, where some profiles give a 403 because he's not allowed access to those, with this identity)
... (as intended)

eprodrom: The user-profile --- you use schema.org, foaf, vcard, ... why didn't you use AS2.0?

deiu: This app is older than AS 2.0

<aaronpk> I don't know if this is going to work, but it might... https://talky.io/socialwg

<tantek> not older than vcard nor hCard :P

eprodrom: API surface? The client needs to pull a bunch of different data from different URLs

deiu: Yes

eprodrom: To document this API for a client developer, I'd need to document all these URLs?

deiu: No, it's just following links.

<AnnB> aaronpk, I thought they said yesterday that the port (?) we need for talky is blocked at the INRIA firewall

<aaronpk> I'm on a VPN

deiu: The API is just doing GETs on URLs of the resources of interest, following links. HATEOAS

sandro: tantek, it uses vcard

<AnnB> aha

<elf-pavlik> http://socialwg.indiewebcamp.com/irc/social/2015-03-18/line/1426710246277

<hhalpin> the rdf vcard vocabulary, which I think is compatbile with hcard

<elf-pavlik> http://socialwg.indiewebcamp.com/irc/social/2015-03-18/line/1426710400225

<AnnB> I get to a splash screen, and no further

<eprodrom> vcard++

<Loqi> vcard has 1 karma

timbl: Code can following multiple links, like the older version of the vocab and the newer version. So one could convert to AS2.0 gradually, with supporting the old vocabs, too.

deiu: To build on that example, using tabulator

<ben_thatmustbeme> evan did

<ben_thatmustbeme> but i can hear

eprodrom, you calling back?

<eprodrom> Sorry, I'm off the phone, trying to work out talky.io stuff

<cwebber2> eprodrom's still on talky at least ;)

<eprodrom> It's actually much better than the phone bridge

<ben_thatmustbeme> really?

<cwebber2> yeah it's not bad

<AnnB> cool beans

<elf-pavlik> kaepora: can you please share link to resource saying that you can't do fragment URIs in JSON? a#b ?

deiu: I'm using tabulator as a generic skin to render the RDF data in my profile as HTML so it can display in the browser
... I can add additional data to my profile, using a vocabulary I make up, for "hometown"

<eprodrom> aaronpk: I just disabled video for that reason

deiu: I just defined a new property, "hometown"
... Now tabulator lets me set values for it
... So *without programming* I was able to define a new profile property, and then apps allowed users to add it.

<eprodrom> ben_thatmustbeme surprisingly so

<AnnB> that's great to learn

<AnnB> those who were remote at the last TPAC said same thing

elf-pavlik: something about templates

<AnnB> really surprising, since the audio is just coming through the webcam

<ben_thatmustbeme> eprodrom, may be more to do with microphone quality than anything

deiu: Lea Verou of CSS WG is doing a PhD (at MIT) on html page templates from data

<ben_thatmustbeme> also can compress the audio first, whereas phone doesn't

<eprodrom> ben_thatmustbeme it felt like there was some kind of bursting going on

<ben_thatmustbeme> eprodrom, yeah, the audio does sound more... muddled, its definitely not as clear but it doesn't cut in and out

<aaronpk> yeah sorry the mic is pointed the opposite direction of the people so you can see the screen

timbl: there are levels of customizablity, default form, styled form, js-controlled form, etc

<cwebber2> sorry I seem to be having connection issues on my LAN

<ben_thatmustbeme> cwebber2, is that you?

<elf-pavlik> deiu: can you please link to more info on what you say happening at MIT in this gh-issue? https://github.com/w3c-social/social-arch/issues/1

<kaepora> elf-pavlik: I just created a big JSON fle and tried it locally

<kaepora> elf-pavlik, I am sure you can replicate the results on your browser :-)

<eprodrom> Who is scribing?

<ben_thatmustbeme> i believe sandro was supposed to be scribe

SoLiD walkthrough on Private Sharing

<elf-pavlik> https://github.com/linkeddata/SoLiD/blob/master/UserStories/PrivateSharing.md

bblfish: Using webid-tls for access control, in this example
... So assume Ian has a WebID (a URI that identifies as him)
... I GET Ian's "card"
... link "acl" (not registed with IANA)
... goes through various headers, eg for CORS

<elf-pavlik> issue including topic of rel="acl" registration https://github.com/linkeddata/SoLiD/issues/10

bblfish: in this example I used turtle instead of JSON-LD, just because it was a little easier for me

<cwebber2> what's the talky url again?

<ben_thatmustbeme> https://talky.io/socialwg

bblfish: shows Ian's certificate

<cwebber2> thx ben_thatmustbeme

bblfish: using cert.pem for curl demo (browser does this automatically)

<tantek> elf-pavlik, don't make an issue of rel=acl registration - just go add it to the rel registry yourself per http://microformats.org/wiki/existing-rel-values

<elf-pavlik> tantek, i see not problem with you having your interpretation on that, but please note that other people interpret it differently

bblfish: Link header to acl resource
... we GET it

<cwebber2> we GET it, man!

<tantek> elf-pavlik, not an interpretation - just a suggestion to you to help you take a productive step forward

bblfish: do a PATCH to add the new bit of access control
... so the client software just allowed jane access
... send notice to Jane

<cwebber2> ben_thatmustbeme, intentionally muted

<cwebber2> I got 3 hours of sleep between prepping user story details and waking up for this

<cwebber2> I don't want to appear on webcam ;p

bblfish: do a GET on her profile

<cwebber2> but i'm on SIP now anyway

<ben_thatmustbeme> yes, i know, but it looked like the camera was just covered, not muted in talky

bblfish: In the example, I show a proposed extension to GET, to include a query, being discussed in HTTP WG

<eprodrom> Thanks aaronpk

<elf-pavlik> Query link header proposal: https://github.com/linkeddata/SoLiD#reading-data-using-sparql

<ben_thatmustbeme> yeah, i was losing talky sadly

<AnnB> aaronpk, should I try hosting talky?

sandro: This is off topic --- we don't need queries to make this user story work

<AnnB> k

bblfish: okay
... We get back a "ping" endpoint
... and you POST to that endpoint. *or* or use webmention

<eprodrom> I think it's jumping the gun to say this is definitely WebMention

bblfish: I haven't yet looked at how webmention works
... the resource you POST to with ping should have ACLs such that you can post (append) but not read, except maybe you can edit the things you created.
... shows diagram, explaining bits.....

<aaronpk> diagram has some typos apparently

eprodrom: I like this flow, it's a lot like activity pump, except the client is responsible for making that ping (where in AP it'd be the server). With fanout issues, it's probably better handled by server.

<hhalpin_> +1 just fixing a URI namespace for microformats

bblfish: Yeah, it could be the server, or some non-client-agent. Although if we want a dumb server, we need and intelligent client.

eprodrom: LDP as stupid as possible? (stupid is good here. not business intelligence.)

<deiu> LDP doesn't do much by design

<hhalpin_> At this point I would keep the URIs at microformats.org rather than w3.org

<eprodrom> LDP + social stuff

sandro: as simple as possible, but no simpler

<deiu> exactly

timbl: as long as the added features are application-independent

<Zakim> elf-pavlik, you wanted to discuss running bots on server which do client logic ...

elf-pavlik: different elements have different responsibilities... Could have a daemon which does stuff.

<deiu> elf-pavlik++ (similar to Apache modules)

<Loqi> elf-pavlik has 24 karma

sandro: it's still black and white to me --- certain things are the responsibility of the client or not.

Arnaud: solid (right now) puts a lot of responsibility on the client

<eprodrom> Aha!

hhalpin: the LDP model is interesting, similar to unhosted in some ways, dependent on access control and auth, maybe

<eprodrom> Interesting

hhalpin: If you had a server, please store any file, it's a problem

<deiu> I disagree with hhalpin_

<akuckartz> hhalpin mentioned https://unhosted.org/ and briefly compared it to LDP

sandro: that's exactly the same with ActivityPump and MicroPub. You still need some identity and auth mechanism.

hhalpin: I think we should talk about TLS later today

<deiu> you're right

sandro: I think they could each use each other's auth system

aaronpk: I think the access control is really similar, and orthogonal to this spec

Arnaud: any more about solid per se, before we get to overall similarities and differences

deiu: SoLiD is relatively new

<AnnB> are melvster's demos related? (that we have not yet seen)

<deiu> AnnB, maybe we can do those demos in the demo session

sandro: The LDP parts of SoLiD are stable and have lots of implementations, the other bits are very much subject to change and improvement

Comparison of Proposals

Arnaud: maybe self-criticism

akuckartz: Maybe instead -- say what's good about the others

<deiu> for the minutes..."What a great idea"

<ben_thatmustbeme> if we can get everyone authenticating to each other, that would be a really big step forward

<elf-pavlik> https://www.w3.org/wiki/Socialwg/Social_API/Comparison

<deiu> ben_thatmustbeme, we can do that in a different WG though

<deiu> as it doesn't only apply to Social

<rhiaro_> scribenick: rhiaro_

<ben_thatmustbeme> deiu, true, I don't mean for the WG to deal with that, the socialwg is specifically avoiding choosing auth mechanism. but if we can get working those developing in the group i think will find it quite useful

aaronpk: micropub is only for writing. Complete picture includes webmention, PuSH and microformats

<deiu> ben_thatmustbeme, I agree

aaronpk: We have lots working reasonably well, where there are holes are getting into propagating information about state changes of objects deep in the tree of comment threads or eg. likes on comments
... we haven't built that stuff yet

<eprodrom> aaronpk I think also access to the social graph (who follows Aaron? Who does Aaron follow?)

aaronpk: which is why I'm not sure about it
... we want to figure out a better solution for that

<eprodrom> And CRUD on profiles

<elf-pavlik> eprodrom: we do *self* criticism :)

aaronpk: the way AS handles that is entirely reasonable, with activities essentially being a changelog of everything that happens
... you can sync systems using changelog

<eprodrom> elf-pavlik thanks very much

aaronpk: the way I figured this out was going through the story and seeing the edge cases. Seeing at a point in the story there isn't a solid answer
... whereas just glancing at the story when we were voting it looked like we could do all of it
... So that was the big one.

<ben_thatmustbeme> eprodrom, thats a matter of publishing that information as a xfn page really. I plan to start doing that soon... following is easy, followers not so easy unless following notifies

<eprodrom> ben_thatmustbeme yes

aaronpk: The whole formencoding and namespacing of command params with mp- in micropub works for all use cases I've encountered, but I can see where there are limitations, we just haven't hit them in practice yet
... maybe it's better to find a solution where we don't have those limitations in the first place

Arnaud: any reactions?

<deiu> rhiaro_++

<Loqi> rhiaro_ has 77 karma

<eprodrom> elf-pavlik am I allowed to respond now?

<ben_thatmustbeme> aaronpk, i would say i started to hit at least annoyances with it for tagging people in locations in a photo

<deiu> rhiaro++

<Loqi> rhiaro has 78 karma

<elf-pavlik> eprodrom, ActivityPump time now so your turn -- Tsyesika speaks ATM

Tsyesika: one thing micropub talked about is ability to get source, eg. markdown rather than html

<ben_thatmustbeme> rhiaro_, loqi knows to ignore _ at the end of a name

<eprodrom> elf-pavlik ah, maybe my sarcasm wasn't clear enough

Tsyesika: I'd love to introduce ability to get that source

<aaronpk> ben_thatmustbeme: locations of person tags wasn't part of the story so I didn't include an example, but yes that's true

<eprodrom> elf-pavlik I don't like being told to shut up

Tsyesika: So ActivityPump doesn't have that

<eprodrom> Understood

Tsyesika: Other thing is no ability to have multiple file uploads
... And multiple steps to upload one file
... [plus metadata]
... One of the biggest problems I have as a developer for activitypump is that audience targeting is always on the activity rather than the object
... but in reality when you're checking someone's ability to access an object when they dereference it, you really need the audience targeting on the object
... it's more useful on the object than the activity. You can get around it with some caching, but it's not great
... has been pointed out that there is duplication regarding post and share activities with objects, but not sure how to get around that without fundamentally changing activitystreams - which I'm not against, but might bring other problems
... Plus discoverability hasn't been cemented yet

<cwebber2> I think having a "source" field on notes and etc would be really nice

various people: helping ann with whiteboard

<cwebber2> would make editing my posts a lot easier when using pump clients that use markdown

Arnaud: anyone?

eprodrom: as part of ActivityPump spec (Jessica did a great job), I would point out that in the federation aspect it calls for using the NOTIFY verb
... I'd really rather see that as a webhook style description mechanism

<bblfish> Is there an HTTP NOTIFY verb?

<cwebber2> +q

eprodrom: Second, it has a number of activity types that are called out for how they change the state of the world
... There should be some finer detail on what exactly happens when you unfollow, when there's a like, etc
... Finally, to go back through and review the user stories and make sure the examples that we have (supported by pumpio)

Arnaud: more interested in big gaps that need filling
... every technology can have open issues, but right now we're more interested in bigger story

<sandro> bblfish, only if you squint

cwebber2: I agree with evan and jessica

<eprodrom> bblfish: https://msdn.microsoft.com/en-us/library/aa142938%28v=exchg.65%29.aspx

cwebber2: One thing I admire about micropub is having a wide variety of implementations

<eprodrom> That's the only reference I can find

<eprodrom> oshepherd probably has more info

cwebber2: we have a good variety of implementations of clients, but for servers there are only pump.io and mediagoblin, mediagoblin only implements half the pump spec
... with activitypump I'd like to see a spec that people *can* implement on the server side

<eprodrom> cwebber2++

<Loqi> cwebber2 has 29 karma

<cwebber2> -q

Tsyesika: to follow on, at lunch we [rhiaro, aaronpk, arnaud] talked about how the indieweb community have split their specs up, and it feels easier to implement

aaronpk: it lets you make incremental progress

<elf-pavlik> http://indiewebcamp.com/IndieMark

Tsyesika: with activitypump it's like you're either compliant with the spec or not, and it's a lot of work to get that done
... someone coming along wanting to make their site activitypump compliant would have a much harder time than getting started with indieweb
... I don't have it on my personal site

hhalpin: can you explain why?

<eprodrom> I don't think it's a "personal site" kind of API

<eprodrom> It's a "social network engine" API

Tsyesika: it's one big spec and it can take time to implement it all, and it's changing a lot. It's a big investment to do it all at once, then change it

<aaronpk> eprodrom, you're saying my personal website can't participate in a social network?

arnaud: something fundamental that makes it impossible to do it this way in activitypump?

Tsyesika: no, we can break it down

<ben_thatmustbeme> it has to be able to, a personal site is a network of 1

Tsyesika: also NOTIFY is probably going to be dropped

<eprodrom> aaronpk, nope

bblfish: don't want to hear sandro speak, don't need to push him to be negative about SoLiD. It means more if I'm negative, as a big defender

<cwebber2> eprodrom, well, I think maybe with sufficient library'ification of activitypump

bblfish: Implementing is very important, that's where indieweb community is great

<cwebber2> we can hit a lot more of the "easy to implement" side of things

<eprodrom> cwebber2, right

bblfish: SoLiD have to learn to create communities too

<Tsyesika> eprodrom: i agree it's more oriented to social network software and being a platform and such but also i think it's useful to be able to implement parts of the spec

<eprodrom> Tsyesika, sure, but I'd have a hard time dividing it into pieces

bblfish: Also AS and pump work is interesting, seems like there can be a mapping to solid

<cwebber2> activitypump is not quite SSL in difficulty to implement, but similarly, having some good libraries like that can make things much nicer

<eprodrom> Also, I think the kind of person who'd be implementing would be doing it for e.g. Diaspora

<aaronpk> cwebber2, but you also have to make it really easy for other people to create libraries because you're not gonna want ot write libraries in every language

<cwebber2> aaronpk, I agree

<Tsyesika> eprodrom: i agree, it'd be tricky, i'm not sure how i'd do it to be honest but it's something i like from the indieweb and it's maybe a good idea to look into if here is anything we could do

<Tsyesika> but yes we want this to work for the diasporas, facebooks, etc. of the world

<cwebber2> aaronpk, I think that the activitypump spec is quite implementable as a library, but it also requires that we put more code into it

bblfish: LDP is harder to implement
... Once the server is done, it's done for everybody

<cwebber2> aaronpk, another thing is until MediaGoblin implemented the pump api, nobody else had done that work. I think we should see if we can share our experieences to make it clearer to implement

bblfish: on the client side there's lots of JS and rdf libraries needed
... it's more theoretical infrastructure

<aaronpk> cwebber2, eprodrom, Tsyesika, I would be interested to see what activitypump would look like broken out into small implementable steps, like what if someone could just create their inbox but wait to implement an outbox

<cwebber2> I'm interested in seeing what that would look like!

<Tsyesika> i'm not sure how it'd look but i think it'd be good to look into

<cwebber2> aaronpk ^^

bblfish: Could do work on notifications that people want in social communities

<eprodrom> Yeah, so, there are ~5 endpoints defined in the activity pump doc

<eprodrom> Maybe more if you count CRUD on user profiles and created objects

<eprodrom> That feels pretty minimal

bblfish: To give more responsibility to the server
... Let server act as a client

<cwebber2> eprodrom, also I'd say that a lot of the work Tsyesika is spending time on is changing the database to support migrations

<Zakim> deiu, you wanted to bash SoLiD a bit

<cwebber2> and I'm not sure how you can get around that complication

<cwebber2> er

<aaronpk> eprodrom, i would feel better about that if it has been demonstrated that it's pretty mininal

<cwebber2> to support federation

<Tsyesika> cwebber2: sure which isn't nesseserly anything to do with specs tho

<Tsyesika> it's just legancy infrastructure

<cwebber2> yeah

<cwebber2> however!

deiu: SoLiD by definition is very generic

<cwebber2> we *can* make it easier

<eprodrom> Migrating from one server to another?

<cwebber2> by sharing information on how we got there

<eprodrom> That's such a hard problem

<cwebber2> eprodrom, no, not that

deiu: it has a different view of what social means to indieweb and activitypump
... especially in terms of notifications

<cwebber2> eprodrom, migrations as in "sql schema migrations"

<Tsyesika> eprodrom: moving a database from a design not intended for federation

<eprodrom> Right

<cwebber2> upgrading the table structure

<Tsyesika> to a database which is

deiu: it's less focused on this definition of social, it's a bit difficult to implement the same user stories
... This translates in a lot of clientside javascript
... as opposed to indieweb where a lot of logic happens in the server
... pages clients see are less heavy
... for SoLiD there are bandwidth requirements you have to meet in the client
... there's also this high-perceived learning curve
... developers are used to implementing apis, whereas we have a different way of managing data

<Tsyesika> eprodrom: i'm going to try and find some time to implement a spec compliant version of activitypump and i'll see what the pain points are

deiu: I think that's the biggest difference
... I think it's a perceived learning curve, it's not that big a deal

<cwebber2> eprodrom, anyway, I think some documents showing how to plan your database from day 1 (the easiest route!) or how to upgrade an existing system will help other developers with adoption

<eprodrom> Tsyesika maybe we could work on it together

<cwebber2> yes

<eprodrom> Tsyesika I want to try a new Go project

arnaud: this touches the point about whether you post the activity and the server creates the post or vice versa

<eprodrom> Or if you have another language you'd like to try

arnaud: an activity or object centric view of the world

<cwebber2> eprodrom, let's write it in guile ;)

deiu: we have a data view of the world

<Tsyesika> just to clarify i said you can use CRUD on existing objects nt to create new objects

arnaud: more generic

<eprodrom> cwebber2 cool here

<Tsyesika> *not

deiu: on the plus side, if tomorrow there's going to be a completely different working group with different use cases, we might be able to help them as well

arnaud: it's more flexible in that respect

<Tsyesika> eprodrom: sure i don't have any Go experience

<eprodrom> Tsyesika me either

<cwebber2> eprodrom, Tsyesika is also learning scheme

<eprodrom> Oh, cool

<Tsyesika> well

bblfish: I think we've got a set of communities that represent a learning curve that come to a full blow generalisable version of SoLiD (?)

<eprodrom> We could do it in Scheme

<cwebber2> now we can make a truly ivory tower version of federation ;)

<Tsyesika> i've played with it on the side :)

bblfish: we're all doing prety much the same thing

<Tsyesika> "learning" is maybe too stronger word

<deiu> eprodrom, one of our Solid servers is written in Go

bblfish: requirements seem to be on one end of the spectrum, minimal technology, to the other side with maximal generality

<eprodrom> deiu, cool

bblfish: we can all learn from each other

<cwebber2> I think this has bee a good exercise, sandro !

AnnB: tim or sandro? or melvster?

<deiu> eprodrom, I wonder if you could fork it to add the pump API

<eprodrom> deiu, it would be an interesting exercise

melvster: I was a semantic web skeptic
... perceived learning curve as andrei mentioned
... spent a year looking at it, adn by the end realised I could have learned it in less time, it's conceptually quite simple

AnnB: Negative comment on solid?

<aaronpk> Tsyesika, cwebber2, how about building an activitypump api and launch on your own websites? :)

melvster: compared to indieweb for example or ostatus, activitypump ecosystems, it's not as far advanced in terms of community
... it's not as far advanced in terms of developers or users

... it's early

<eprodrom> aaronpk, that's really a great idea

<cwebber2> aaronpk, yes I'd like to do that

<eprodrom> But I'd like to have a proof-of-concept first

<Tsyesika> i fully intend to use whatever i make on my website

... It's hard to document, hard to get across that it's simpler than the perceived learning curve

<cwebber2> eprodrom, something I've thought of

<Tsyesika> i/we

<cwebber2> Tsyesika, also

<cwebber2> maybe making something like a "Disqus" for activitypump

<cwebber2> I got interested in this when I realized the endpoints can point off-server

<eprodrom> heh

<cwebber2> so static publishing people can have a federation panel still

<eprodrom> Yeah that's pretty cool

akuckartz: you have to get in and understand what linked data is about. I'm pretty sure ibm, boeing, would be able to do that. People who don't have those resources - is it possible to modify or restrict the proposal for SoLiD so that the implementation curve is reduced?
... with the purpose of making it easy for others

<eprodrom> Why?

<eprodrom> I mean, why would I have to do that?

akuckartz: who never dealt with semantic web, to adopt spec

<ben_thatmustbeme> cwebber2, eprodrom, thats exactly what tantek was talking about last F2F with the desire to always support static sites

<eprodrom> If I understand JSON-LD, why do I have to do my Semantic Web meditation training

<eprodrom> ?

<cwebber2> ben_thatmustbeme, yes, it took me a while to understand what that meant

<Zakim> elf-pavlik, you wanted to propose discussion about evolution of the whole system, extensible design and backward/forward compatibility

<sandro> imho, you don't eprodrom

<cwebber2> ben_thatmustbeme, but when I got it I got kind of excited about how to do it with activitypump

<eprodrom> sandro, I don't think so either

<cwebber2> hence my post about it to the list

elf-pavlik: I'd like to propose discussion about evolution of APIs, especially breaking changes
... power of web by showing opening an old webpage in a modern browser
... could analyse apis this way, how they could be broken by certain design choices
... how to avoid this in future

<Zakim> deiu, you wanted to suggest we rename SoLiD

deiu: maybe SoLiD was not the right name for this spec
... We should remove the parts of the spec that aren't relevant to the workign group from the spec
... we started writing the spec with a state of mind in which we wanted to document the whole thing that we were doing
... that's too much at this point, for this group

hhalpin: when we were writing the charter we knew we were going to have something liek this problem

<Loqi> deiu has 5 karma

hhalpin: most of the world using json based apis
... this could change next year, I find it unlikely
... the microformat html based approach has advantages, but we didnt' write this in the charter because most people want to ship around json not html
... and we want to be open to enterprise use cases
... we thought we'd have more enterprise membership to the group
... but that's changed, we have a much more open sourced, hacker based community
... on that basis, I could see revisiting json as charter requirement
... in terms of rdf communities, the amount of people using json and html vs json-ld is smaller
... using RDF is powerful for people who want it
... I'd be concerned if we did an rdf *only* spec
... json-ld was trying to fix that
... I wasn't thinking about html microformats case when writing the charter
... microformats2 does have json version, we could massage something there
... I'm hoping json-ld plus parsing html could bridge these communities
... the goal of any decentralised social web should be to bridge, we don't want three decentralised silos
... ideally we don't want three different standards, we want one standard that allows the different networks and different communities to do what they want with rich communication
... I'm hoping URI extensibility will help with this
... Charter isn't written in stone, but when I was writing it this is what I was seeing

<eprodrom> _1

<eprodrom> +1 I mean

hhalpin: there are a number of high level things that are the same

timbl: Feeling of deja vu
... back in the xml days... json is the new xml
... the xml and rdf communities were born at about the same time

<eprodrom> Poor rhiaro_

timbl: everyone was committed to xml, and rdf should be as xml like as possible
... that was a massive mistake

<elf-pavlik> rhiaro++

<Loqi> rhiaro has 79 karma

timbl: rdf is simpler than xml
... by trying to make an xml syntax it was horrible
... should have used turtle originally

<eprodrom> Actually timbl is being pretty slow-paced right now

timbl: a few companies have had similar experience
... a guy said he wasted three years looking at rdf through xml glasses
... so json is just a shoe-in for xml
... incentive because it's used in javascript
... you can't address things within a json document
... something about blank nodes
... json is interesting, and helping people get from one to the other is interesting, but potentially counterproductive, I'm torn
... try A/B
... take one set of developers and give them a json world, and another set who forget json and think about core rdf model
... think about that, send turtle across the wire
... and you'll find yourself empowered because yoru life is simpler
... can merge data streams by concatenating files
... you can build any application on LDP without the store having to know anything about it
... they are different philosophies
... we're designing new stuff
... the number of people using json at the moment is in some ways totally irrelevant
... there is an excited turtle community
... we should provide something that does not require json
... and allow turtle directly

arnaud: I can see there are differences that could be easily accommodated between different approaches, and combined
... like content negotiation, format of data can be accommodated
... solutions that support several different formats
... some differences are harder to accommodate
... some that use a single entry points, some more restful
... this is harder, you go one way or the other
... aaron and jessica acknowledged some of the other stuff can be used to learn from
... there are points of convereance we can identify

<Zakim> sandro, you wanted to suggest the contexts can bridge to microformats and form-encoding

sandro: I think having an implicit (or explicit) json-ld context, basically we can get form encoding and microformats to be json-ld
... they're really close

<hhalpin_> My hope is that JSON-LD could basically, with some auto-conversion on server or client side, could be the lingua franca.

sandro: then we're down to vocabulary mapping question
... they're different vocabularies

<hhalpin_> Vocabulary mapping can be worked out, they are not super-different

sandro: hoping one community could switch
... no idea what politics of that are

<hhalpin_> There seems general consensus around a HTTP REST model.

<ben_thatmustbeme> getting those vocabulary difference documented would be a good step on that

sandro: Big thing about static sites being different wrt being restful
... but you could say a static site is like restful funnelled through one endpoint
... if you don't do that, you can go through individual URIs
... discover of that could be painful, but may be worth while
... Also, seems like ActivityStreams is sending across changes in an application specific way
... in the end SoLiD don't have a way to do this
... but we've talked about it having an application non-specific ways to send changes
... like a diff stream
... don't care what kind of data, just want changes to any kind of data
... my inclination is towards the generic one
... curious, people who work on ActivityStreams can they consider giving up on terms like Like

<eprodrom> ??

sandro: why do you want to explicitly like something rather than just say you changed some data

<eprodrom> ben_thatmustbeme, yes all of us

<eprodrom> Since we're publishing it as a spec

arnaud: more powerful, but harder to get there

<deiu> eprodrom, I'll take a stab at AS for our apps

<ben_thatmustbeme> eprodrom, you mean all pump.io group? indieweb has not yet really found AS2.0 to be useful, as the different philosophy of everything is a post. but I'm thinking it makes a lot more sense in the notifications sense

eprodrom: addressing harry's point. If you look at these three systems, if you take something like solid and remove webid requirement, add specific containers that are related to each user (folllowing, followers, favourites, ..) and you require some server side behaviour, you've got activitypump
... if you favour activitystreams as main vocab and favour json-ld serialization
... they are very close
... the outlier is micropub
... micropub is going to survive regardless
... but we could do something like activitypump informed by SoLiD design
... and suggest micropub as a social api for (??)

<ben_thatmustbeme> eprodrom, didn't mean to interrupt you, was just finishing my thought.

eprodrom: we canc ome out with two specs

arnaud: I think evan jumped the gun

eprodrom: I'd rather not describe our group as three different camps
... in competition
... we have to ship something
... I'm not sure a competitive framework it he one we should be working

<Tsyesika> I'm not so sure micropub is all that fundermentally different, after talking to aaronpk more these two days and looking at amy's work it looks like there could be some resolve a lot of our "differences"

<sandro> Right -- we all have pretty much the SAME GOAL

eprodrom: whatever group decides, I'll hold my nose and get it done, but won't necessarily like it

<ben_thatmustbeme> Tsyesika, i'm very interested to hear your thoughts on that.

hhalpin: we weren't hoping on staying competitive
... that was to force people to compare each other to find commonalities and differences
... we're at the point where we can solve some of them
... we're clearly seeing some convergence
... hoping json-ld can be converted into mf or turtle

<ben_thatmustbeme> theoretically if we did switch micropub to json instead of form encoded, likely as some other version of MP, how much would that change usability by the other communities?

hhalpin: the devil is in the detail of vocabulary alignments, link headers etc

<eprodrom> ???

hhalpin: In terms of what evan said about indieweb, worth noting that indiewb has the most grassroots developer adoption

<eprodrom> hhalpin_, can you justify that?

hhalpin: One of the critques when we started this group is that w3c has tendancy to be overly complicated and drive away developers

<eprodrom> We have hundreds of thousands of users on pump.io

hhalpin: So how can we simplify what everyone is doing

melvster: we had this group a few years ago run by RMS called GNU consensus

<eprodrom> I count well less that 100 using indieweb

melvster: idea was to get social web components to talk to each other

<eprodrom> ben_thatmustbeme in response, no, I mean the social web wg

melvster: tried to condense to 'hello world' use case, but it failed because no social web groups would talk to any others
... now we've seen we've all solved similar use cases
... can we get all groups to focus on a minimal use case to talk to each other

<sandro> eprodrom, be what about number of implementations? I think that's IWC's claim.

hhaplin: we already have use cases

melvster: for test suite

aaronpk: that was the goal of creating SWAT0

<eprodrom> sandro, yes, and if we go by whether a spec has odd or even number of characters in it, I think SoLiD wins there

hhaplin: ideal situation we have api and common data format and we use that for common use cases

melvster: can we test it?

hhalpin: yes we will

arnaud: part of the process is creating a test suite and showing interop

melvster: by the next f2f?

<eprodrom> sandro, although I think we might have more pump.io clients than there are implementations of the indieweb stuff

<eprodrom> sandro, https://github.com/e14n/pump.io/wiki/Clients

bblfish: we should implement these stories

<eprodrom> Really?

hhalpin: goal of standardisation workgroup is to produce a standard, not to have a nice time and learn from each other
... if we produce a standard we fail, or produce a standard with low adoption or contradictory standards, also fail

<Zakim> elf-pavlik, you wanted to propose convergence driven by queries on the (social) datasets

arnaud: we're nowhere near there yet

elf-pavlik: we haven't moved much on querying or accessing data
... evan mentioned with indieweb you can't get social graph and relationships
... from the resulting data, we can derive requirements of api
... with linked data, by following your nose you do it in the same way

<bret> Is there a Zakim or tally room?

elf-pavlik: could be some interesting ways of approach resulting dataset

<hhalpin> It can work, we have seen this with WebCrypto where we got every browser implementing the same crypto API despite underlying differences (NextGen Crypto API, NSS, ec.)

elf-pavlik: then find some common ground

arnaud: break until the hour

<ben_thatmustbeme> eprodrom, huh? perhaps i should rephrase, how many have actually implemented and are publishing an AS2.0 stream

<eprodrom> ben_thatmustbeme, to what point?

<cwebber2> ben_thatmustbeme, the spec isn't even out yet

<eprodrom> That it doesn't matter because it's not implemented?

<eprodrom> We're publishing it. It's our job to ship it.

<hhalpin_> I sould assume we will be implement AS2.0

<eprodrom> It's ridiculous that we'd turn up our nose at the spec that we are producing and saying it's not good enough because it's not implemented.

<hhalpin_> if we don't, we should not ship it as a spec

<eprodrom> Or we should fix it

<hhalpin_> However, it's still quite early

<ben_thatmustbeme> eprodrom, indieweb philosophy is to work out an implementation that works, then spec around it. I'm not suggesting that. I'm saying implment it too

<hhalpin_> I think we will have a problem if in a year from now there aren't AS2.0 implementations

<eprodrom> ben_thatmustbeme, right, I understand that.

<ben_thatmustbeme> before the spec is done, because you will never have a spec finished unless you start implementing

<eprodrom> ben_thatmustbeme, I totally agree

<hhalpin_> Re the indieweb approach, I tend to agree

<eprodrom> On the other hand, I don't like to implement things multiple times

<ben_thatmustbeme> i was just trying to see who is publishing as2.0 streams NOW, as they can better make statements about where it is and isn't useful

<eprodrom> I especially don't like to put my users through a lot of incompatibility pain

<eprodrom> "Sorry, I implemented an intermediate version of the spec, now all your feeds are broken."

<ben_thatmustbeme> eprodrom, doesn't mean it has to be on a large system, but you still need some sort of system to test it

<eprodrom> ben_thatmustbeme, I agree

<ben_thatmustbeme> direct question, do you have a published intermediate version of an AS2.0 stream? that I can right now try to consume

<eprodrom> No I do not

<eprodrom> But there are test versions in the test repo

<eprodrom> Which might be good for you to start with

<ben_thatmustbeme> okay, so If i start playing with implementations, I'm not looking at anything else. So I may end up with a lot of suggestions for changes on the MF2 version of it

<eprodrom> sandro, blunt question

<eprodrom> Is SoLiD just CrossCloud rebranded?

<eprodrom> The name slipped earlier

<eprodrom> I don't think that's a bad thing but I'm kind of confused by the whole 'keep it general for all kinds of apps' thing

<eprodrom> I reallllly think CrossCloud is a great idea

<ben_thatmustbeme> general question that i asked and i didn't see any response... if I wrote a MP client that posted with json data instead of form encoded, would that be more interesting to compatibility building? what would still be lacking? argue points better or worse, etc

<eprodrom> Neat

<eprodrom> I'm OK

<eprodrom> Just a lot of beeps

<Arnaud> we had to reconnect the bridges

<Arnaud> we're on a break

<akuckartz> ben_thatmustbeme: We are still having a break.

<eprodrom> Yes

<ben_thatmustbeme> Arnaud, yes

<Arnaud> ok

<Arnaud> thanks

<eprodrom> Thank you

<Tsyesika> eprodrom: i'll try and get these issues worked through and then we should work on a basic implementation

<Tsyesika> makes no sense with all those open issues

<cwebber2> I'm interested in collaborating on a basic implementation, and am flexible on what language

<cwebber2> as long as not php ;)

<Tsyesika> i'm flexable on language too

<Tsyesika> but it looks like the issues on it atm will cause a big chnge

<Tsyesika> *change

<Tsyesika> if eprodrom wants to try out go it's all good for me

<eprodrom> Tsyesika: let's see how the conversation goes today

next meetnig

<Tsyesika> okay

<bblfish> Arnaud: advantages of continuing next week is that we should keep the momentum

<eprodrom> Agreed

<aaronpk> whiteboard photo:

<scribe> scribenick: bblfish

<eprodrom> Nice handwriting

Arnaud: we could have a debriefing meeting next week
... anyone objects to not cancelling next meeting?

... RESOLUTION: Continue next week

<akuckartz> aaronpk++

<Loqi> aaronpk has 796 karma

<bret> Thanks for the whiteboard photo

Arnaud: several ways we could imagine resolving the differences. We should discuss the strategy

<bblfish>1+

Arnaud: we could just continue resolving issues

<aaronpk> better photo:

Arnaud: or we could just bite the bullet and go from there.

<Zakim> aaronpk, you wanted to talk about authentication in the APIs

aaronpk: differences between our API and jessica, we could arrive at a compromise and explore that possibility. We need to look at this more. We now can see how things are similar and different
... also we could make a point about authentication: it appears that all three APIs use verifiers with tokens, we could leave the way to get the token out of the API, and leave that for the next API.

<elf-pavlik> http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html ?

<deiu> rhiaro++

<Loqi> rhiaro has 80 karma

aaronpk: I was surprised to see a lot of convergence

<rhiaro_> commonground++

<Loqi> commonground has 1 karma

<AnnB> that's the reason to have F2F meetings!

<rhiaro_> note, sandro just indicated he sees common ground between SoLiD and micropub

<rhiaro_> so that's the full triangle :D

<elf-pavlik> bblfish: to common ground seams to be notion of container and posting to containers

<AnnB> people work stuff out more easily when actually in person ... not to mention with pizza, sushi, wine, beer ...

<AnnB> triangles are the strongest foundation

<elf-pavlik> https://www.w3.org/wiki/Socialwg/Social_API/Comparison#Endpoint

<elf-pavlik> bblfish: also some use POST everything

<elf-pavlik> ... maybe some mapping would allow finding common ground

<akuckartz> convergence++

<Loqi> convergence has 1 karma

<elf-pavlik> ... i see common understanding that thanks to JSON-LD we can think in RDF level and still people can use it as plain JSON

<elf-pavlik> ... one can consider AS2.0 as cristalization of RDF (rel to article bblfish wrote year ago)

<elf-pavlik> https://blogs.oracle.com/bblfish/entry/crystalizing_rdf

<elf-pavlik> bblfish: we should automatically find a way to produce it on LDP servers

<cwebber2> full_triangle++

<Loqi> full_triangle has 1 karma

<elf-pavlik> ... i can with my tools in very generic way and at the same time people who don't want to use those tools (yet) they can still interoperate

<Zakim> elf-pavlik, you wanted to propose continue with showing implementation of User Stories

<bblfish> I mentioned RDF: crystalisation here: https://blogs.oracle.com/bblfish/entry/crystalizing_rdf

elf-pavlik: we should write implementations of the top uses cases and get feedback by doing that.

evanpro: i feel like we're stretching the amount of time we're getting out of this community to begin with, the idea that we'd write multiple implemenenations for the continually iterating different standards, and spend time evalutaing them and figuring it out...

evanpro: i'd rather put that time towards a single standard

<AnnB> +1'

... rather than splitting that time among multiple standards

... i'm not sure this convergence is going to get easier

... i feel like we've already put off this decision once, we need to start coming down to what the social apis are going to be if expect to ship it by the end of the year

... i'm sure that our friends here on w3c staff are optimistic about having our charter renewed

<deiu> Isn't that a bit premature?

... i'm not sure i have the mental capacity to continue doing this if we never actually come out with results

evanpro: we need to bite the bullet fast, or else the charter cannot be completed

<sandro> Don't we have 20 months left?

... my feeling is there is some urgancy, we probably need to make some tough decisions

Arnaud: we are not expiring at the end of this year, at the end of 2016

<eprodrom> Thanks for the correction

... i agree we don't want to waste time, but it's also not as critical as you just described

<eprodrom> Yes, 2016

<sandro> http://www.w3.org/2013/socialweb/social-wg-charter

... to have a recommendation by the end of next year, we better have a solid proposal by the end of this year

... there's still a lot of work

.... i agree by the end of this year we'd beter have a good idea of what this looks like

hhalpin: next steps: from each of the three communities, we should choose an author from each community

... to help filter to an editor a draft editor

... or two editors, who is neutral, not in any of the camps

... to try to push a converged document out

<Zakim> elf-pavlik, you wanted to mention that current drafts already start or even address federation

hhalpin: want to operationalise what evan said. Next step: from the three communities we should choose an author from each community one or two draft editors, to push a draft document out to see if we can get consensus

elf-pavlik: it seems that some of the candidates addressed federation

hhalpin: we probably won't be able to include federation

Arnaud: or maybe we'll have it beacuse it's built in

hhalpin: one author: the author writes a lot of the text, and the editors does ?

hhalpin: you need at least one neutral person who doesn't really care to help balance out arguments that arise

AnnB: the reason i'm asking is after dec 11 i'm free, and i'm a good editor

Arnaud: to get back to the point, the proponents seem to be in agreement to give people a bit more time to choose a starting point, to experiment a bit further

<hhalpin> JSON-LD has the author/editor distinction - http://www.w3.org/TR/json-ld/

... i'm in favor of doing this , because i rather we start with a more constricted approach rather than saying so and so is winning

<AnnB> I will not have time before I leave Boeing ... but can probably help edit after I leave

<hhalpin> Or just all editors, but we need at least one neutral person in case there are severe disagreements

<hhalpin> Also, we need to see what the implementation commits are

... there is value in holding off for a little more

Arnaud: prefer to work towards a more constructive approach, so there is value to holding off a little bit more. Agree that it is unrealistic to have everybody make three implementations.

akuckartz: would it be possible to start with writing what is accepted as common ground?

<ben_thatmustbeme> I have to go... headed to the ER

<eprodrom> elf-pavlik: do any of these proposals not do that?

<eprodrom> Or is that just a point of commonality?

<cwebber2> how about rhiaro? :)

AnnB: what about making an outline? fill in the bits that are known now

<ben_thatmustbeme> these kids don't want to stay in her

<eprodrom> rhiaro_++

<Loqi> rhiaro_ has 81 karma

akuckartz: maybe start with a wiki page and collect the common ground

<elf-pavlik> +1 rhiaro if she would like to take on this challenge

<aaronpk> sandro: i dont think the editors need to be neutral, they just need to be enthusiastic about whatever happens

<eprodrom> ben_thatmustbeme WOW! Go do that!

<ben_thatmustbeme> yeah, so I'm off

<cwebber2> ben_thatmustbeme, wow, good luck!

<eprodrom> ben_thatmustbeme It's gonna be great!!!!

... how do we handle syntaxes.

<hhalpin> HTTP REST(ish), common vocabulary (re microformats and ActivityVocab), and fix the HTTP headers so they are common

Arnaud: if there are issues that can be expressed independently of the implementation, that can be addressed

<eprodrom> concrete steps with deadlines++

<cwebber2> could we have a prototypes deadline?

<cwebber2> yes

aaronpk: to avoid the issue of endless postponing lets have some deadlines

evanpro: what i'd like to get an idea of is what we think would be some changes in the state of the WG now that would show us that we're movign forward

<cwebber2> +q

eprodrom: what would be some changes to the state of the working group that would show us moving forward.
... ?

<aaronpk> .. concerned about jessica not having time to keep editing the AP doc

<aaronpk> .. or the solid people drop out because there's a new version of java it can't run on

<deiu> java?

eprodrom: what are the changes that happen that we get going further?

.. i'm more cocerned about what are the change that happen that make us sure we're going further

.. i'm not sure there's a clear positive way forward, is it that we create a SoLiD/actvitypump/micropub spec?

.. is it we find something that's the olowest common demoninator (which right now HTTP)

.. what will the change be next time we sit down in japan

eprodrom: I don't know that there is a clear way forward? Is that we create a spec with the lowest common denominator which I think is HTTP at present. How do we see the way forward?

.. the only change i see that is likely is that we lose members and lose interest

Arnaud: maybe we have different perceptions

eprodrom: the only change I see is likely is that we loose members and move forward

.. because you're missing out on being at the meetingand at lunch

.. my feeling is there's a lot of common ground and recognizing this and seeing ways of converging

<rhiaro_> It's come through that people care a *lot* this last couple of days

<rhiaro_> Hopefully we're past worrying about falling apart now!

<bret> Generate 3 specs and let the best spec win? ;)

.. we can use every week to say how's that going

<cwebber2> setting a deadline on that checkpoint is a good idea

.. it's a bit pessmiistec right now to say we're going to waste time and lose members

<Zakim> elf-pavlik, you wanted to mention we already agreed for 'follow your nose' during last F2F

elf-pavlik: i'll try to experiment with different workflows to work between telecons

.. i see github and irc very practical

<elf-pavlik> https://github.com/w3c-social/social-arch

.. also for writing the document, trying to capture following the nose idea

<bret> ack lost connection :(

<Loqi> aww, cheer up

<aaronpk> Arnaud: we're quickly running out of time

<aaronpk> hhalpin: one way to focus the group would be to not raise as many issues, because issues take a lot of time to reseolve

<cwebber2> +1 on that

... especailly RDF issues, which take a lot of time and are of limited relevance to everyone

.. allow the editor to have discretion

.. if people are really upset about that, let'sd do it on an issue-by-issue basis

.. second thing is in terms of authentication, we need to have a generic, i think the bearer token comment was en point

.. the w3c will liekly be starting a web authentication working group in the fall

.. the work is pretty baked already, around fido

.. we need to keep that out of scope

.. in terms of next steps, i'm happy to have aaron and jessica work and maybe someone from SoLiD

.. but two or three people need to take responsibiltiy for converging

cwebber2: i think having aaron and jessica and osmone from solid try to find what the common ground is is a great idea

.. it seems like a lot of progress happened in this f2f whereas the last one the message was implementations win but we were going to end up rubber stamping somehing we already had

<rhiaro_> I agree with cwebber2

.. maybe after these converstaions happen, we can start to establish what are the prototype implementation goals

.. i do agree we should be moving into implementation phase pretty soon

bblfish: i think these 3 groups are woring in different layers, so it's quite easy to get them to agree if we understand the different layers

.. as i was saying earlier, the container stuff is a container, what i'm seeing from activitystreams is a certain vocab which has certain side effects

.. it's kind of a specialized convtainer which does special things

.. turns out most of it has been already written

<elf-pavlik> container ~= endpoint? https://github.com/w3c-social/social-glossary

.. i disagree with harry about the rdf vocab, if we can think about the modeling correctly, we'll be able to narrow down much more quickly

<Zakim> deiu, you wanted to mention "browsing the social graph" as the common denominator

deiu: we're talking about the smallest common denominator, but we haven't really decided how to model basic things

.. like users and identities

.. so how to we get to see and browse each other's social graph

<eprodrom> What about AS 2.0 vocabulary?

Arnaud: it'd be useful as a first step to list capabilities and features that we want to have

.. it would go along the lines of having an outline of what we want the spec to cover

.. we've seen through the deep dives we made there's a certain operation we expect to be able to have

<cwebber2> a question is, how will that be different from user stories?

.. what are the basic blocks we need ot have for this api

.. not getting into the details of what the blocks look like

<cwebber2> will this be a shared technical requirements requirements?

<eprodrom> B-)

.. one of the features of the indieweb is the modular approach

.. we don't start building a big spec, we define little specs with different modules

.. wecan experiment and argue over those different blocks

deiu: classifying all these items would also allow us to see whether some of them are relevant or not

.. which means we might be able to remove some of the work ahead of us

eprodrom: two questions. the idea that we're trying to define the basica building blcoks, isn't that what the user stories were for?

.. if there's really a lot of question about syntax/strucre, do we need to stop our effort on AS2.0?

<hhalpin> syntax is JSON-LD with pre or post-processing

.. my understanding was we were going to publish AS2.0 as the social data syntax

<elf-pavlik> issue-15

<hhalpin> unless there are serious objections

<trackbot> issue-15 -- AS2.0 Vocabulary in many ways duplicates microformats.org and schema.org efforts -- closed

<trackbot> http://www.w3.org/Social/track/issues/15

.. if we are not in agreement, do we abandon that effortt?

<hhalpin> In terms of the vocabulary, we just need to map those replications

<cwebber2> I agree with Evan that both we have AS 2.0 anyway, and also wondering what the difference this would be from user stories

<cwebber2> I really don't want to go through a user stories thing again

.. seems like we need to move the AS2 effort forward, and if we're questioning that, we need to steb back and re-evaluate

<rhiaro_> AS2 isn't set in stone right? even if it's not right yet, we can change it to make it better

<rhiaro_> rather than starting over

<aaronpk> Arnaud: the user stories don't define functional blocks

.. they inform you as to what they might be

.. with regard to the social API, i don't think anyone has been arguiing to drop AS2.0

.. so if we throw that out, we'd be that much closer to the situation harry was describing

<cwebber2> PROPOSAL: All specs put forward by the group require AS 2.0 :)

.. but in fact, we've even heard that aaron, who makes no use of AS2 today said he'd have a use for it

.. so let's not be too dramatic about this

<Zakim> elf-pavlik, you wanted to very shortly mention extensibility e.g (currently ActivityPump only supports Follow and Like action + relevant collections)

elf-pavlik: we didn't get to talk about extensibility today

.. solid is super extensible

<eprodrom> elf-pavlik, INCORRECT

.. activitypump defines some actions but isn't extensible

<eprodrom> That's not true at all!

.. indieweb has some vocab dilemmas, what do i do if i get terms i don't know how to render

<hhalpin> +1 extensibility

<hhalpin> -1 discussing it endlessly

<hhalpin> We have URI-based extensibility which should work with ActivityPump as is

<eprodrom> "8.2 Activities The core of any [ActivityStreams] based protocol is activities within. Users post activities to their outbox, from which they are distributed to recipients' inboxes. ActivityPump places no restrictions on the activities which may be distributed; however, it defines certain activities with special behaviors"

bblfish: if we can reuse as much existing technology, ontologies, then we can get out a whole bunch of problems

<rhiaro_> implementation++

<eprodrom> elf-pavlik ^^^

<Loqi> implementation has 2 karma

.. i was just loking at schema.org

<hhalpin> Micropub has mp-

<hhalpin> so...

.. then i understood what they were doing

<hhalpin> we have URI based extensibility and the ActivityVocabulary

.. so maybe we can get to the core, specify the key integration points and reduce our workload

<hhalpin> just see what points there are schema.org+microformat overlap with ActivityVocabulary

<sandro> eprodrom, it'd be good if you could give us a walkthrough of that. How does an enterprise do travel-authroization (the example that came up yesterday) over activitypump?

Arnaud: i'd like to close the meeting

<hhalpin> Not superhard.

.. i think we made good progress

.. if nothing else, sharing a lot more understanding, which is critical to being able to converge

<eprodrom> sandro, sure, I'd love to

.. so i hope we can buildon that and continue

.. i would like people to seriously consider if they are up to being an editor or not

.. we don't want people to volunteer unless they are 100% committed

.. if you get in the way it's not going to help

.. it's not just editing the document, it's keeping track of the resolution...

.. answering public comments

.. i'm not trying to discourage people , just want to make sure they know what it takes

<eprodrom> jasnell does a lot of work

<aaronpk> MEETING ADJOURNED