From W3C Wiki

Social Web Working Group 2nd face-to-face

18 Mar 2015

See also: IRC log


elf-pavlik, fjh, confroom, bblfish, bret
sandro, Tsyesika


Summary of Action Items

[NEW] ACTION: Email re github issues [recorded in]
[NEW] ACTION: hhalpin to discuss re github [recorded in]
[NEW] ACTION: hhalpin to discuss with rigo travel budget to see if more funding can be found for a Paris event [recorded in]

Summary of Resolutions

  1. meet at TPAC, Sapporo Japan 26-30 October
  2. we are not going to meet in Paris
  3. the WG encourage co-evolution and bridge-building across Social API candidates, instead of competition towards a date-driven selection
  4. the WG will prefer follow-your-nose architecture in the API candidates we consider

<Arnaud1> trackbot, end meeting

<AdamB> don't think we've dialed in yet

<bblfish> I tried the teleconf password but could not connect to the telephone

<bblfish> I get "this password is not valid"

<Arnaud> yeah, hold on

<bblfish> thx

<bblfish> can people in the room hear us?

<Arnaud> no

<bblfish> nice placement of cameras

<bblfish> yes, we can hear room much better as yesterday

<elf-pavlik> room looks and sounds good!

<bblfish> the nice thing about being here is that I could just lie down on a bed and still participate

<elf-pavlik> no, that audio worked well!

<elf-pavlik> please unmute it back :D

<bblfish> yes, you have been muted

<bblfish> me and elf can have a parallel meeting in the meantime

<bblfish> I could hear the room for a second

<Arnaud> ok, we're on the bridge now

<bblfish> the phone is working

<bblfish> now we can hear someone type very heavily

<harry> my proposal is that we focus on IG and WG relationship until the rest of the crew shows up

<bigbluehat> scribenick

<bigbluehat> scribenick bigbluehat

<bblfish> I did not realise the audio had been moved, but there is a lot of background noise on


<Arnaud> scribenick: bigbluehat

<bblfish> Sandro are we hearing you type?

User stories

<bblfish> in talky

harry: will the interest group be able to help us understand add the IG user stories to our API requirements

<bblfish> ok back on telephone, can hear better

<bblfish> ah ok. let me try again.

AnnB: I think what I'm hearing is that your asking the IG to clarify their user stories

there's a larger group that have several +1's


there are many with minor objections

AnnB: there are 19 or so about which there is consensus
... the IG can work on clarifying the ones about which there is some debate

<harry> PROPOSAL: We start with the user-stories with complete consensus against all the current API candidates, and then the IG goes to get clarity on the rest. If clarity is gained, then the IG can propose them to the WG.

ben_thatmustbeme: starting with just the top 7 is too limited

sandro: the idea is that the IG will take the lead in clarifying the user stories?

AnnB: the IG will need to involve the WG members in the clarification process
... get the people who care about it, clarify it, "sandro thinks this" "randall thinks that" and then document it

harry: if it's a very clearly defined task, it will get more involvement from the IG
... and once that's complete, it should be clearer what how the WG can proceed with testing

<elf-pavlik> AnnB, let's set date next week for Use Case TF call?

<Arnaud> you're on the phone, aren't you?

<bblfish> can you tell us more about what you are doing at the IG?

<Arnaud> henry?

<tantek> good morning #social

AnnB: the group started collecting user scenarios
... everyone was supposed to transfer them to a common template
... a lot of content never got transfered
... which started the WG working on "tweet form" use cases
... there is a task force looking at architecture
... there was an earlier workshop that included a block diagram

harry: it was an advisory board task force
... we do have a diagram that could be the basis of an architecture description
... there will be a lot of vocabularies
... that will have small but important user communities
... that should still be supported by the vocabulary task force work
... asparagus farmers market use case

<tantek> I'm skeptical of use of any edge case use case (farmers / asparagus) to drive anything in the WG

eprodrom: is the social IG tasked with looking at other parts of the social world that the W3C should be looking to charter WGs for

AnnB: the IG is looking into that

harry: that may be being addressed more in the future

<bblfish> I am in favor of those use cases: not that we have to implement them, but a protocol that can be shown to implement them is a better protocol

<AnnB> Social Web "block" architecture:

eprodrom: I would be concerned that the IG would spend time back filling what the WG has already done

AnnB: I agree

<bblfish> I quite skeptical and a few others are too about the need for a federation protocol.

<tantek> I am in favor of focusing majority of our time on discussing common consumer / user use-cases.

eprodrom: looking at parts of the diagram, and filling in what's missing would be best

AnnB: of the 90 use cases, many of them mentioned missing or unclear information

<tantek> In general I applaud skepticism about the need for any particular new protocol or format.

<bblfish> good idea by AnnB

AnnB: someone mentioned that we could pull those out and work through those concerns
... which would be helpful

<bblfish> I'll be happy to participate, and this seems like a good role for the CG

tantek: a lot of the feedback was that some of them were duplicates

AnnB: goal is to get through the 50 or so about which there were questions

tantek: I'd like to see definitions that include statements of what's in use today to accomplish things

<elf-pavlik> simple diagram on how IG could coordinate various CGs working on *domain specific* vocabulary requirements

tantek: ideally with links to the tools that are being used to accomplish those things today
... if we can solve other edge cases, even better...but let's start with what's being done today

Arnaud: the people who proposed the stories should have the burden of documenting them in that way

sandro: AnnB asked what would be helpful for the IG to do
... what I think would be really really helpful would be to get other people interested and helping

AnnB: I don't think there are many
... not that have their own internally crafted technology

or sharepoint, or yammer, or jive, or IBM connections

harry: thoughtworks mentioned that they also build internal social networks for enterprise

<harry> there's also VMWare, Socialcast, SAP Jam, SugarCRM, Jive, Atlassian, Yammer, Sharepoint

AnnB: we've tried IBM connections. it'd be interesting to know what other enterprises use IBM connections, etc.

<Loqi> Tantekelik made 1 edit to Socialwg/2015-03-17

sandro: does this IG need W3C invited access?

harry: yes.

AnnB: I'd love it if there were more big companies represented in the IG

<bblfish> I'd love to help big companies do this

sandro: we need (from the IG) do a lot more outreach

eprodrom: the user stories that we have from the IG are specific to the API. there are many more user stories addressing in the social space
... there are not yet federation user stories for example
... there are a lot more stories needed in this space

<bblfish> I am not sure how you distinguish social apis and federated apis

eprodrom: the asparagus one came's interesting...but that's not one we thought we could handle in this version of the API...or that we wanted to really attack

<elf-pavlik> we also don't have stories for *querying* social data

bblfish: there's always going to be one part that's completely new...we want something that works across silos
... this is why you won't find a lot of systems doing this...because they're always thinking internally
... it's really very uninteresting

<harry> I think we have agreement here

bblfish: you have to be about the size of an enterprise before it becomes interesting

<harry> I think EvanP used to have a start-up that did this sort of thing, i.e.

eprodrom: are you serious? there's a lot of these...yammer, etc.
... it doesn't make since to say we're only building this for distributed social networks

bblfish: there are a lot of faux social networks

<harry> That being said, we do agree on distribution is a good thing, but it's not a trivial problem

bblfish: that the data gets split around


<harry> I'll explain the federation next

bblfish: in issue-19...
... there is an organization that works with a lot of other organizations


bblfish: they're a lightweight company that uses 60 different tools that are not interoperable with the data fragmented about the place
... the point is that if we only look at what exists, we're only going to duplicate the problem
... the pain the social networking people are feeling
... they're going to have to heal the fragmentation these people are feeling

<harry> I agree that looking at only existing solutions is not enough, but I'm worried that a focus on non-existent solutions may not be super-productive.

<aaronpk> can we cut down on the monologues today?

bblfish: we need to allow these things to tie these things together

<harry> At least at this stage in the WG.

<sandro> +1 aaronpk

bblfish: tantek was saying I want these stories to be about things that exist

<sandro> PROPOSED: all speaking turns limited to 1 minute

bblfish: if we do that, we only solve problems we know about

<eprodrom> I'm going to take a walk for a minute

<elf-pavlik> +1

harry: when we were chartering this working group the main reason was the open social crud
... we do think it's important to have common interfaces
... the reason why we separated this...while a lot of the distributed stories that include authentication, etc. actually get very difficult
... pubsubhubbub and others have proven that they're harder problems to solve
... the social wg may not be able to solve these problems in one go
... happy to have the IG look at these other areas
... and have the WG focus on the current ones

<bblfish> thanks harry for the context for why the distinction was made

<Zakim> tantek, you wanted to mention social web software that works across silos

AnnB: to be clear, I support exploring these, but not sure I have the technical skills to lead that

tantek: I wanted to +1 eprodrom's statement that there are many other social networks in usage in many places
... if you don't think something exist, ask

<harry> So I'm going to point out why federation is hard:

<harry> 1) Authentication

<harry> 2) Groups and Access Control

<harry> 3) Queuing/re-ordering/timing

<harry> 4) Push/pull architectures

tantek: if you really don't think something exists, rather than claiming something exists...there are experts here in many other fields...does anyone (of them) know about X, Y, or Z?

<harry> 5) overload of small servers

tantek: we don't actually have proof of non-existence

<harry> (i.e. scalability)

tantek: bblfish claimed that there is no social network software that doesn't work across silos

<harry> Hisotically this has really caused problems for Salmon Protocol, Pubsubhububub, resulting in Magic Sigs, etc.

tantek: that's false, the indieweb work does work across sites and communicates with the silos
... pretty much all of these implementations support POSSE to federate to the silos

<harry> I don't believe the LDP has solved these in any way that at least I've seen in a live demo or with scalability, although I know they are working on it.

<bblfish> yes, though I was not interested in communicating with silos, but linking the silos together

tantek: or use backfeed...taking the interactions on the silos, bringing them back into the personal sites

<harry> I also know the IndieWeb community has made progress (i.e. what Tantek) has said

<bblfish> so that there would be no more silos

<harry> I would love to know evan's take on this, as he has most experience in coding previous round of solutions

<aaronpk> elf-pavlik: how's that?

tantek: those are all provable and inspectable

<aaronpk> great

<elf-pavlik> aaronpk++ sandro++

<aaronpk> good! this is the logitech cam

<Loqi> aaronpk has 744 karma

AnnB: obviously my experience is in a huge company
... I'm curious how many people are involved in the big of a community that is

tantek: you can measure by the IRC participation...or the number of peopled editing the wiki
... or deploying on their own sites
... known or wordpress+ indieweb plugins
... or more custom things
... number in the thousands
... it's part of why we're working to keep things as simple as possible
... to get thousands of deployments

<sandro> zakim has a feature time time speakers. we can set it to 1 minute... or 2 minutes....

<elf-pavlik> very established in Paris

AnnB: what are some of the other things going on in Europe, mid-sized companies, etc?

<harry> elf has done great work getting diaspora involved

tantek: there's a lot of these groups not represented

<ben_thatmustbeme> sandro++


<AdamB> 3 minutes / topic?

AnnB: like all of China

<Loqi> sandro has 8 karma

tantek: there are lots of diaspora users in europe

<harry> W3C's efforts by the European Commission


<sandro> (it might only work for people who were on the queue)

harry: there are lots of European projects funded by groups within the EU
... all expect for their future government efforts they want better social specifications
... they're not coders
... we do have a lot of European governments that are members

AnnB: why aren't they involved?

harry: I tell them we don't have code yet...and the timing is bad for them
... I have invited some of them as invited experts

<elf-pavlik> +1 change the time

AnnB: well let's change the time

<AdamB> zakim++ on keeping us on task !

<Loqi> zakim has 1 karma

harry: point is that another group growing in size is governments local and otherwise
... there are more people watching than it appears

<harry> UK govt Innovation advisors Nesta, Finland, Iceland, Spain (Podemos), all expect to use some version of the API and ActivityStreams at some point

<harry> or buy a solution from some vendor :)

bblfish: some of these groups are not build software they're tying them together

<harry> W3C funding for this project is not from membership dues but from European Commission,

bblfish: what we want to remove are silos completely
... one social web

<tantek> Known is probably the best software to use to try out IndieWeb features / formats / protocols

bblfish: there's know center


bblfish: players of all size can communicate without any henderance

<AdamB> bblfish++ for being succinct :)

AnnB: in our dreams we would get rid of silos...but it's a good goal

<Loqi> bblfish has 5 karma

<harry> People in Europe do find the 7:00 PM time hard and 6:00 PM time CET

AnnB: harry was saying there were lots of players interested in these activities

<elf-pavlik> AnnB++ meeting in Paris :)

<Loqi> AnnB has 10 karma

<bblfish> +1 for Paris

<harry> We can the IG or WG meeting earlier if there's real desire.

AnnB: perhaps we should have a meeting in Paris...would they come to a meeting?

<bblfish> I can get people in Paris to come to a meeting

AnnB: if have of this team is going to be a meeting, maybe have a WG or IG meeting with them there

<elf-pavlik> i can invite friends from Edgeryders

harry: it is difficult to get people involved there...but we could get someone there

AnnB: tantek are you there?

<harry> +1 doing something

tantek: I'm there...but pretty booked

AnnB: I think it'd be a good time to engage people

<harry> I will point out I will not likely be there unless some magical money appears

<harry> but Wendy Seltzer can substitute

Arnaud: we'll talk about the meeting next
... we started this discussion to discuss user stories
... we mentioned that there are ones with some issues
... and getting the stake holders together to clarify them

<Zakim> tantek, you wanted to be clear that IndieWeb software is not dependent on silos, it works peer to peer and to also note that goal should be get rid of YOUR use of silos, not get

<elf-pavlik> harry, can you publish a wishlist with what your *really* need to get to that meeting? (travel tickets, accomodation, etc.)

tantek: I agree with bblfish that we should not be dependant on silos

<bblfish> cool, I need to look at the indie web protocols more that do this.

tantek: on the indieweb we use webmention to communicate with each other...rather than depending on silos
... I don't think it's reasonable to try and get rid of silos

<harry> ACTION: hhalpin to discuss with rigo travel budget to see if more funding can be found for a Paris event [recorded in [[1]|]]]

<trackbot> Created ACTION-51 - Discuss with rigo travel budget to see if more funding can be found for a paris event [on Harry Halpin - due 2015-03-25].

tantek: it makes us look laughable to propose that
... if you want to get rid of silos, try and eliminate your use of whatever means you can

<bblfish> yes not really trying to get "rid" of the silos, but more allow a technology that makes silos link into the web.

<elf-pavlik> harry++

<Loqi> harry has 6 karma

eprodrom: we're here at the W3C...looking at the list of members...including twitter, google, facebook
... they're not looking for us to destroy their businesses
... they're not involved here...which is fine

<AdamB> what is the goal of this topic? are there more valuable things we can be talking about? just asking :)

eprodrom: we do have a social data standard that we're laying out
... companies can and should use
... we're working on an API that companies can and should use to communicate together

<melvster> facebook was part of the social web XG, they were interested in adopting activity streams and opensocial ... back in the day

eprodrom: and a federation protocol that they could also us

<harry> melvster, that's not true

eprodrom: what I'm unhappy about is assuming a singular community...and ignoring the other tasks to serve a specific community

<melvster> harry: it is, check the minutes

<harry> David Recordon showed up for one phone call right as he got hired by Facebook

eprodrom: we do have a task to standardize social data

<AnnB> sorry to say, harry is correct, melvster

<harry> They never joined the XG

<harry> He did one meeting and never came back
...two: to standardize social APIs

<harry> He is now doing cloud work.
...three: if we can manage to get a federation protocol started

<melvster> oh ok, maybe not part of the xg, but on the telecon ... the other statement is correct
...three: if we start with changing won't happen
... if we start with smaller things, then we'll get farther

<tantek> I think the way we have any chance of getting companies outside the WG to adopting standards is as simple / minimal standards as possible.
...three: I don't want to undercut that

harry: W3C has done outreach to Twitter, facebook, and Google
... and some with Microsoft because of Yammer
... Google was against open social
... facebook has nothing to do with this group...they don't want this work at the W3C

<bblfish> yes, agree that one does not change everything, one has to lay the foundation to make it easy to cover the innumerable use cases that will appear.

harry: twitter is interested, but they don't have an open standards advocate
... they're continuing to watch as it evolves

<harry> I just wanted people to know the state of outreach

harry: companies have resourcing issues and don't have cycles to dedicate to standards

<Arnaud> ack

<harry> We are doing outreach, we've done outreach to Weibo etc.

<harry> We plan to do more

bblfish: I completely agree one has to build something that can grow


bblfish: we should acomodate growth in use cases
... the linked data cloud should be taken into account

<AnnB> bblfish, you should join the IG

bblfish: that's another crowd of people that would be interested in our work

<harry> danbri1, if you have any ideas of what would be useful to Google do tell us, the question is re-occuring

Arnaud: let's move on

<sandro> If they'd be interesting, bblfish, why wont they come to these meetings?

Arnaud: let's try and settle some dates and locations for the next meeting
... the logical next meeting would be 3 months from now

<bblfish> sandro, will be interested to find out. Perhaps they were put off in one way or another

Arnaud: we got an invitation to participate in TPAC
... for scheduling purposes we should figure that out sooner than later


<AdamB> i would suggest to do take advantage of tpac

<harry> TPAC is Sapporo the week before Halloween

tantek: I propose we do meet at TPAC

<bblfish> mhh, why is Zakim reducing my speaker time even when I am not speaking?

<tantek> Proposal: we do meet at TPAC

Arnaud: many of us are going to be at these meetings anyway
... there was discussion on the mailing list
... there is an AC meeting in Paris

<harry> I discussed with W3C internally, there is some feeling that outreach and discussion with Asian members about the WG would be great.

<sandro> bblfish, zakim just watches the queue. When the queue's not used, it's wrong.

Arnaud: TPAC is in Japan in October

<Loqi> Tantekelik made 1 edit to Socialwg/Social API/Candidates

<elf-pavlik> I can only do Europe, till we get strong Online Identity in place and broadly recognized :)

<tantek> PROPOSAL: meet at TPAC

tantek: I want to see if we can get +1's for TPAC

<AdamB> +1

<harry> +1

<tantek> +1

<rhiaro> +1

<AnnB> +1

<mattl> +1

<elf-pavlik> +0 can't go anyways

TPAC is the last week of October...including Halloween in Japan

<bblfish> +1

<bblfish> ah that is far away

<Arnaud> +1


<harry> TPAC alternates between Europe, USA, and Asia

<harry> So next year will be Europe, then back in USA

AnnB: if you don't know TPAC is when most WGs hold their F2F meetings, to enable cross-fertilization

Arnaud: there are WG meeting M-T, W is reserved for technical plenary
... run as an un-conference even
... on various topics
... because there are many groups meeting, it's prone to cross polination
... last year we had a meeting with the Annotation WG
... I totally agree that it's a very valuable event

<bblfish> But it is also very expensive to go to Japan

harry: I think that's consensus on meeting at TPAC
... I want to revisit the Paris thing
... there will be a Future of the Web conference in Durham NC
... if folks want to meet there

<bblfish> yes, I agree it looks like the Paris meeting was not debated

RESOLUTION: meet at TPAC, Sapporo Japan 26-30 October

harry: being organized by shepazu
... it's not an official W3C meeting

<rhiaro> +1 Paris!

<elf-pavlik> +1 Paris

<AnnB> +1 Paris

harry: what are the dates for the Future of the Web thing?

<harry> bigbluehat, ask Doug

Arnaud: for Paris, do we have a preference of day?

tantek: puts in a note to avoid conflicts with CSS
... asking the AB not to meet at TPAC

<bblfish> Advisory Board?

<AnnB> Advisory Board

<AnnB> me/ (or AnnBassetti or ArtBarstow ;-)

<rhiaro> In May, there's an IWC in Germany 9/10th which is same week as AC meeting I think?

Arnaud: the AC meeting will be W-Th
... one possibility is M-T

<harry> So for those new to the W3C, there's a BIG meeting called TPAC

<harry> for the WGs

<harry> and also a yearly meeting called the "AC meeting"

<harry> Which is Advisory Committee

<harry> which helps

<harry> and meets

<harry> twice a year.

<harry> The TP meeting is also 'Technical Plenary'

AnnB: several participants are going to IWC in Germany

harry: I think rather than doing an official face-to-face, we could just do an outreach

AnnB: I think we should make time to bring a meeting to Europe

harry: I would support a meeting in Europe...even if it's a just a single day

Arnaud: with a one day meeting, then folks from the US won't come
... I'm interested for now to schedule a F2F

AnnB: I propose a May 4th and 5th Paris F2F (a M&T)

<elf-pavlik> +1

<Arnaud> PROPOSED: May 4-5, in Paris

<elf-pavlik> +1

<tantek> �-1 conflict

AnnB: elf-pavlik and bblfish have been on the phone for 2 days solid

<AnnB> +1

<rhiaro> +1

<harry> +0 (depends on rigo and travel funding)

<Tsyesika> +1

<bblfish> +1

<Arnaud> +1

<cwebber2> +1

<ben_thatmustbeme> 0 i won't be able to be there in person

<harry> I would be happy to do outreach

<AdamB> how many chairs need to be present for that ?

<aaronpk> -0 I won't be able to go since that's too close to my other plans

<harry> to get Europeans there who are interested but not W3C members

bblfish: it happens to be at an interesting point of time

<sandro> -0 seems pretty soon

<elf-pavlik> bblfish, no more dealines for demos!

<elf-pavlik> just no discussions *unless* demo

bblfish: that would be the time of the demos

<sandro> bblfish, that proposal for a deadline failed

eprodrom: plan was to have demos in the next 4 weeks for ones that exist

<tantek> Counterproposal: Europe in July, adjacent to IndieWebCamp Edinburgh 7/25-26

<eprodrom> +0

bblfish: when were the implementations needed to be ready by?

<sandro> evan: 0 abstain on May 4-5

bblfish: that would be a good time to demo

<Loqi> I added a countdown for 5/3 10:00pm (#5656)

<harry> Let's do a proposal for July

<harry> and then see what date has more support

<bblfish> I am also fine for July

<rhiaro> I'm also fine for July, but elf-pavlik can't come to UK

<AnnB> -1 Edinburgh (I would not be able to get travel approval)

tantek: we gave up on that. we have 3 candidates. new candidates need to show up with implementations that match user stories

<Tsyesika> UK is easier for me than paris

<elf-pavlik> -1 Edinburgh

<tantek> +1 Edinburgh

<Tsyesika> +1 edinburgh

<harry> The festival is later in August

<harry> i.e. not July

rhiaro: the conflicting month in Edinburgh is August

<eprodrom> -1 for planning a meeting until we know what we're planning for

rhiaro: starts the 7th of August

<elf-pavlik> bblfish, yesterday's resolution

<harry> +0 (again, travel funding issues)

<AnnB> yo, dret ... we're voting on the possibility of a WG meeting in Europe ...

Arnaud: 23rd-24th of July in Edinburgh

<bblfish> can one kill the Zakim?

<elf-pavlik> looks like Paris had few more +1 ?

harry: I'd be surprised if we can't get a room with the University of Edinburgh

bblfish: there will be too many henry's around

<bblfish> who is opinionated?

rhiaro: elf-pavlik can't come to the UK

<AnnB> either: tangent to W3C meeting in Paris May 4-5 OR with IndieWebCamp Edinburgh 7/25-26

rhiaro: so that's still a problem

<bblfish> ;-)

<harry> eprodrom, I agree that it's a bit silly to plan for meetings without agenda but some kind of regular heartbeat is needed.

<ben_thatmustbeme> I cannot hear half the things people are saying honestly

<ben_thatmustbeme> and I'm in the room

Arnaud: if we're not doing this thing in Paris, I would vote to do a 3 day meeting next time

<bblfish> +1

<eprodrom> harry: agreed, but I'd like to have a goal

Arnaud: these f2f's are very least 2.5 days would be good
... and help folks travel back

<eprodrom> Like "federation protocol ready for editorial"

<harry> eprodrom, I'm hoping the goal will be consensus on a first FPWD for the Social API

bblfish: the sun doesn't set in Edinburgh in we could do 3 full days in 2 days time

<elf-pavlik> we could try to arrange stay and working space for everyone very near Paris -

<harry> The question for me is whether or not we can do all the work in between this meeting and then to map the

<harry> use-cases to candidates and hash out most of the technical issues

eprodrom: it's important for us to meet. I would like us to have a particular goal for that meeting
... harry mentioned having a FPWD ready

<harry> A 1st FPWD of the API was my goal for *THIS* meeting

<harry> but alas, it seems we now have 3

eprodrom: federation protocol draft
... it'd be helpful to know what subject we'd be meeting about

<harry> (thus my objection to user-stories, but I think as a methodology it makes sense)

eprodrom: May 4th & 5th is 6 weeks from now

tantek: July is a better mid-point between now and TPAC

<cwebber2> +q

<bblfish> +1 for July also

<tantek> +1 for July

<cwebber2> -q

<tantek> +1 for July 22-24 range

<cwebber2> +q

<AnnB> -1 July ( would not be able to get travel approval)

<rhiaro> +1 July

<Arnaud> PROPOSED: Edinburgh July 22-24 (adjacent to IndieWebCamp)

<cwebber2> (my queue slot is not related to scheduling btw)

<tantek> +1 Edinburgh July 22-24 or July 23-24

<cwebber2> 0

<elf-pavlik> -0 can't go there untill we sort out solid Digital Identity system :S

<Tsyesika> I think we should go somewhere elf to can get to


<rhiaro> I agree Tsyesika

Arnaud: it's good that we've agreed on Japan in October

<Loqi> I added a countdown for 10/17 8:00am (#5657)

Arnaud: but we should determine some dates for the inbetween meeting

<tantek> Counter-proposal: don't meet between now and TPAC

tantek: I'm OK if we don't do an in between meeting

<eprodrom> +1

<bblfish> I think July is a good idea

<sandro> My french isn't great. Is viable for July 22-24?

<harry> In Paris I can book Centre Pompidou

<harry> even if I'm not there

<bblfish> But people could also meet in Paris who are interested in specific topics. Eg. LDP groups

<harry> They have a perfectly good meeting

Arnaud: I'm wondering if we should extend the phone calls by 30 minutes
... I've done that with other groups and it's been helpful
... it makes time for all the admin stuff we have to do at the beginning

<harry> I have a lunch conflict if we extend 30 minutes

<bblfish> +1 for 1h30 proposal by Arnaud

tantek: I think most of the calls have completed on time

Arnaud: we respect the limit we have

<elf-pavlik> we could look at securing all the place to stay and meet + food in Paris to reduce expense for participants

Arnaud: it doesn't mean we couldn't use more time

<harry> I would prefer we try to make the administrivia very quick.

tantek: I'm not sure most of those issues are worth synchronous time

sandro: what's the alternative to synchronous time?

tantek: issues in tracker or IRC

sandro: or email?

<harry> Most produtive WGs I know eventually move to github

Arnaud: tracker is just there to say there is an issue
... not to communicate over the issue

<elf-pavlik> +1 github issues!

<harry> W3C has its own repo as well

sandro: we could use github issues

<harry> It works well and we can automagically archive to the email list

<elf-pavlik> see e.g.

cwebber2: it does seem that we get to some of the topics at the end
... maybe 15 minutes?
... 15 minutes more on the call

bblfish: I'm happy with an hour and 30 minutes
... it does bring up the where are we discussing things discussion
... it's not clear where things can be discussed

harry: recently everything has a tracker and or a GitHub issue tracker
... I'm happy with an extra 15 minutes
... but not 30

<elf-pavlik> PROPOSAL: we use github repo for each *product* hosted in single organization e.g.

<AdamB> i agree with the underlying theme of what Arnaud stated, it seems like the topics that are holding up making forward progress tend to happen at the end of the meeting. i understand the lack of desire to be on a 90 minute meeting. what about trying out an extra 15 minutes for a few weeks and then see how it is working?

harry: concerning too many channels, every WG I know uses wiki, tracker, sometimes github
... people seem to do fine

Arnaud: let's forget the meeting length extension for now

<harry> ACTION: Email re github issues [recorded in [[2]|]]]

<trackbot> Error finding 'Email'. You can review and register nicknames at <>.

Arnaud: it's 10:45...I think we should break

<harry> ACTION: hhalpin to discuss re github [recorded in [[3]|]]]

<trackbot> Created ACTION-52 - Discuss re github [on Harry Halpin - due 2015-03-25].

<bblfish> yes, harry people use that, but what is the issue database we should use?

<tantek> trackbot, I don't blame you.

<trackbot> Sorry, tantek, I don't understand 'trackbot, I don't blame you.'. Please refer to <> for help.

cwebber2: my topic may not be good before a short break

<harry> In general we'd migrate off tracker and move to git/hg

cwebber2: it's not clear what's happening after this other than discussing API or federation

<harry> that's what most produtive WGs I see eventually do

cwebber2: my main question may or may not be trying to address an elephant in the room
... it seems to me that some of the directions over the last couple days

<harry> Again, the authorized channels for discussion is IRC, email, wiki as well as a tracker/git/hg

cwebber2: is "don't discuss the technical direction; talk about the user stories"

<bblfish> I mean what github tracker is one meant to use for general discussions? it seems like the AS2.0 one is ok for issues on AS2.0 but not on say issues on Protocol, since that has not got a git repo.

<harry> +1 technical discussions of the APIs in our next session

cwebber2: at the end of yesterday I began to get very worried that we don't have an undertanding
... there's a rift that AS is a way overly technical direction
... and I'm concerned about the rift

<harry> We basically associate tracker only to meta-issues, and all deliverable-specific issues go to github

<harry> seems to work well

cwebber2: we explicitly don't have technical user stories
... and I'm concerned that's going to be insufficient

<harry> General discussion is the usual IRC/mailing list/telecons

<tantek> I fully expect to see implementation subsetting of ActivityStreams -- �too much in it that is unnecessary for interop with popular consumers user stories.

cwebber2: and that we're not addressing the rift

<bblfish> harry, the person talking is speaking about the group potentially splitting, and at the same moment you make a comment that everything is going fine

<harry> People can always leave the WG, that's OK and normal, but we generally seek convergence

cwebber2: and that bringing this up is lobbing a grenade into the middle of the room
... and that half the group is going to stand up a flip a table in response
... I don't know what the solution is
... and we haven't talked about it at all

<elf-pavlik> cwebber2++

cwebber2: at the end of yesterday it sounded like the indieweb folks were not for implementing AS2.0

<Loqi> cwebber2 has 14 karma

<sandro> +1000 cwebber2

cwebber2: I hope we don't have a decision between this and the next meeting...where half of the group says this is completely against my technical direction...and I'm not going to implement it

<tantek> cwebber2++ for speaking his mind and politely so.

Arnaud: we're discuss this after the break

<Loqi> cwebber2 has 15 karma

Arnaud: we do need to discuss general direction

<harry> I think it's more important to understand cross-cutting issues in API

Arnaud: we also have API and federation on the agenda

sandro: Andrei came willing to do some LDP demos

tantek: another thing we asked people to do was cut short the federation conversation in the demos
... maybe we should allow that to kick of the federation conversation

<bblfish> how long is the break?

Arnaud: it's set. let's have a break. then we can go back to trying to convince each other

RESOLUTION: we are not going to meet in Paris

AnnB: what about people who are not meeting right now?

<rhiaro> AnnB++

<Loqi> AnnB has 11 karma

AnnB: the people not here are likely the people who would meet in Paris

<rhiaro> I would go to a meeting in Paris, official or unofficial

<eprodrom> I would rather do Paris than Edinburgh

harry: If there's not a strong objection from tantek I'm fine with folks meeting in Paris

<eprodrom> May > July for me

<harry> I will likely not make Paris but I would not object.

AnnB: I think there are others in Europe who aren't able to vote because they're not currently here

<tantek> wait til TPAC > July > May for me

eprodrom: I'd rather not meet in the summer, and just meet at TPAC

<bblfish> I am happy to meet everyone in Paris in May

rhiaro: why don't we do a for May and July?

<bblfish> we can make some space here, and just work on specific topics

<eprodrom> +1 Doodle poll

rhiaro: and give people a few days to respond

<tantek> +1 Doodle poll

harry: as long as we agree by next meeting

<bblfish> 10 minutes?

<bblfish> ok

Arnaud: let's have a break for 10 minutes

<elf-pavlik> We could do it together with some of the next events in Europe

<eprodrom> ACTION eprodrom to make doodle poll for f2f between now and TPAC

<trackbot> Created ACTION-53 - Make doodle poll for f2f between now and tpac [on Evan Prodromou - due 2015-03-25].

<melvster> elf-pavlik: re the agenda, I think it would make sense to discuss issue 17 (Identity, Agent, Person, Persona, Account etc.) *before* other issues, as it affects the other issues

<melvster> building an API without identity as was tried with ostatus didnt work ... let's learn from that

<elf-pavlik> AFAIK sandro and jasnell (and of course bblfish) have the best overview on that

<elf-pavlik> IMO bblfish may have certain bias here ...

<melvster> bias?



<tantek> melvster - not sure what you mean by bias

<melvster> tantek: it was a question, elf brought up bias

<elf-pavlik> yesterday we already got hot exchange about /#me thing

<tantek> in IndieWeb we found it was much simpler / more sensible to build micropub on top of IndieAuth / identity

<tantek> in terms of user-flow

<elf-pavlik> tantek, IndieAuth at this moment looks like pretty insecure since it doesn't require HTTPS or at least people don't use it...

<elf-pavlik> also fkooman brought couple of issues with state parameter etc.

<tantek> elf-pavlik: nope IndieAuth works with or without https - up to the indieweb site to choose

<melvster> +1

<tantek> thus it builds upon user agency and preference

<melvster> what I tried to tell fkooman

<tantek> everyone listed on level 3 support uses IndieAuth 100% with HTTPS

<bblfish> WebID could possibly also work without HTTPS

<bblfish> not secure, but well

<tantek> elf-pavlik: rather than claim "doesn't require HTTPS or at least people don't use it" please instead *ASK* "can it work with HTTPS and who uses it?" since you don't know.

<tantek> bblfish: that's my understanding of WebID as well

<bblfish> for example one can use openID to verify a WebID

<elf-pavlik> i know it can, just at least from fkooman's feedback most people don't use it or if they do have insecure https config on their servers

<tantek> this is false: "most people don't use it or if they do have insecure https config on their servers"

<elf-pavlik> i hope he'll write post about it soon

<tantek> refuted by the citation I gave above

<tantek> level 3 support and higher

<melvster> elf-pavlik: discussion on identity can be heated, that's because it's personal to so many people, that doesnt mean it's not worth discussing, at least as a building block for the other issues, imho a standards group should aim towards interoperability, whatever the individual viewpoint

<tantek> don't care what someone claims - anyone can inspect the raw data

<elf-pavlik> i very much like approach IndieAuth takes, just it may need more in depth security review

<melvster> why? facebook got to 100 million users with http

<harry> everything is moving to HTTPS

<elf-pavlik> melvster, we talk about client-server HTTPS or server-server HTTPS ?

<elf-pavlik> client-server without HTTPS puts people using wireless hot-spots etc. under great risk for anything requiring authentication

<elf-pavlik> server-server HTTPS different story but still I find benefits to use it there as well

<elf-pavlik> just different degree of staying exposed to MitM attacks

<harry> exactly elf

<tantek> elf-pavlik: ++securityreview!

<tantek> I've started added security review questions and such for exactly that reason

<cwebber2> let's embed pgp authentication into the spec, it's the only solution we have to bring real security for our users ;)

<cwebber2> #obvioustroll

<mattl> cwebber2++

<Loqi> cwebber2 has 16 karma

Arnaud: we should agree on what we want to use the time for.
... lunch is coming to us today
... we have the afternoon up until about 5:30
... we need to talk about federation
... we should at least touch on the subject

<cwebber2> -q

Arnaud: we have at least 1 demo

deiu says 5

tantek: are they related to user stories

eprodrom: I'd like to do federation, demos of LDP, and social API criteria?

Arnaud: before the end of the day...split between them in some way

<elf-pavlik> deiu, maybe later you would have some tips on how LDP deals with 'MediaObjects'

eprodrom: can we address federation protocol strategy for the next hour?

Arnaud: that's reasonable

eprodrom: sounds good
... the way that our charter has been layed out is that we'd be taking a staged approach
... syntax
... api
... federation protocol
... "if we manage to make it may only be a note" -- referencing the charter
... it's important for us to delivery something, but we do have some waivering out on the fed protocol

<elf-pavlik> or API *could* solve federation as well...

eprodrom: we've talked before about syntax informing API which would in turn inform the federation protocol
... if we continue with that strategy, then I think the next steps are to work on the API
... and let that inform federation
... if we have 3 candidates, we should at least sketch out how federation would look on each of those protocols
... because the selection of the API will flow into the federation choices

<Loqi> Tantekelik made 1 edit to Socialwg/2015-03-17

eprodrom: I'd like to see how things might work with
... I'd assume WebMention for micropub

<cwebber2> eprodrom++ re: looking at what federation would look like following that api

<Loqi> eprodrom has 6 karma

eprodrom: and what if any system might exist for an LDP strategy
... this is coming up at 11:20, and I don't think they need to be held to a high standard because of time...but I think it's a good place to start

sandro: I'm trying to determine the distinction between the API and the federation protocol
... is it about relationship of the user to the service providing the API?

eprodrom: I think when we talk about federation it's about security bounderies
... I can't log in to aaronpk's site and post there
... but I can publish to my own site
... and I can send a notification to aaronpk or Boeing
... and they can choose to do something with it
... it then in turn chooses to pluck a feed in a pull fashion

<elf-pavlik> my-frontend<->my-backend<->other-backend<->my-frontend vs. my-frontend<->my-backend || other-backend <->other-backend

eprodrom: I think of the API as a client to server protocol and federation as a server-to-server protocol

<aaronpk> (since evanpro can actually log in to my site and see content i've shared with him privately)

eprodrom: I believe micropub and webmention are client-to-server then server-to-server

sandro: LDP has explored both. deiu demo will hopefully cover some of that

eprodrom: there's nothing in LDP that precludes it syndicating it out elsewhere, correct?

Arnaud: correct.

eprodrom: if I publish to my site, and then having that be syndicated out to other peoples inboxes is entirely possible, right?

Arnaud: right.

<Zakim> tantek, you wanted to note that in IndieWeb, there was a natural split between work on federation protocol (Webmention, Vouch), and API (Micropub), and it turned out federation was

tantek: sandro asked about the distinction between API and federation
... some of it can be architectural
... in the indieweb community it emerged
... from what was being built
... the federation protocols ended up being really really simple
... webmention is a simplified version of pingback
... there are other APIs that also need auth

<AnnB> Andrei Sambra = deiu

<AnnB> on W3C staff

Arnaud: do you agree with eprodrom definition of API and federation?

tantek: I'm not sure about that.
... some of the demos that you saw yesterday was server-to-server
... servers talking to servers

eprodrom: yes. they are web servers talking to web servers

<elf-pavlik> webmention also works my-frontend <-> other-backend e.g. input on

tantek: server as user agent

aaronpk: I don't think client-server vs. server-server is a good definition

sandro: I think it's about trust boundries

AnnB: in our case, when suppliers begin adding social features to their tools

<elf-pavlik> both server and client can send web mention to my understanding

AnnB: then we'd like to federate that into our social tools
... we don't have control over too much

sandro: you don't clearly have ownership over everything, but you want it to cross bounderies

<elf-pavlik> just as both clent and servers can use LDP

tantek: that's a great point. we have this same problem in the indieweb

<sandro> "federation crosses control boundaries"

tantek: one is to silos, and one is peer-to-peer
... with the silos its a bunch of "snow flake" APIs

tilgovi: are you trying to make a distinction that they're all different? or are they user-to-user vs. user-to-server?

tantek: we have both.
... we have POSSE
... and we have on that pulls from the silos

aaronpk: the term is related to every silo thinking their service is special

tilgovi: the answer is that every API is different, then.

<AdamB> POSSE -

<elf-pavlik> webmention ~= pingback

tantek: with peer-to-peer API there is one API: WebMention (and sometimes the Vouch extension of that)

<AdamB> webmention -

tantek: and in the other case, we use POSSE

<Loqi> Tantekelik made 2 edits to Socialwg/2015-03-17

<AdamB> vouch -

eprodrom: in networking terms, we'd call that using a bridge

tantek: right. we're bridging to support federation
... we put perma shortlinks into the body of the copy to follow your nose back to the original
... when using POSSE

eprodrom: looking at broader federation systems...

<bblfish> qhow can one standardise snowflakes?

eprodrom: in email, the user connects to their server using POP, IMAP, Exchange, etc.

<bblfish> q how can one standardise snowflakes?

eprodrom: servers talk to each other using SMTP

<bblfish> q: how can one standardise snowflakes?

eprodrom: there is that separation between the two

<tantek> bblfish: we typically don't want to because snowflake APIs are so horrible

eprodrom: XMPP actually names them c2s and s2s
... they separate, but very similar protocols

bblfish: in the standards there's a snow flake federation that is probably un-standardizable

<tantek> we have a better chance of asking silos to implement simple standard APIs *in addition* to their snowflakes

bblfish: so we can't really look at that
... a number of the other protocols are server-to-server

<cwebber2> +q

bblfish: can that not just be done using the LDP API?
... can that person not just add a statement that they want to be pinged at a certain URI?
... there is a super set of HTTP that's going to be completely identical between the client and the server API
... what would be interesting is to have the common piece move up the stack
... so there's very little distinction

cwebber2: the distinction is a little less valuable in the "pump-a-verse"
... there's someone who's built a twitter-to-pump thing
... and it got shutdown
... you can just build bots that do those thing
... they're not that they get shut down all the time.
... it doesn't seem relevant to dealing to the silos
... federation is about dealing with the peers

<bblfish> me above: yes be as little difference as possible between the "client" and the "federated" api, so that one can use the same stack to program both.

AnnB: in certain situations it is true it's not about working together
... but we have so much to tie together, that federation is valuable
... internally we are trying to federate between silos
... I'm just saying there are co-operative silos

cwebber2: the main interest in dealing with silos is that users are stuck in it
... and it's hard to get out of it
... or get your friends out of it
... I'd love to be behind federation to silos, but it seems you can deal with it without adding it to the federation discussion

<eprodrom> bblfish: I agree, good idea there

<ben_thatmustbeme> second on cwebbers point that we don't need to discuss federation to silos

cwebber2: in part because you'll likely get shut down

tantek: if you're abusive or throttled, you'll get shutdown
... let's just ask who's been shutdown

eprodrom: but you don't provide other people access to a separate client to twitter

tantek: lots of reasons twitter shuts things down

eprodrom: that might be one of them

<sandro> +1 cwebber2 it's probably out-of-scope for us to talk about the social/legal problems of bridging

tantek: we have bridgey that does this
... assuming you copied your content to twitter

<elf-pavlik> +1 don't get to much into discussion about bridging to silos ...

tantek: originally it just supported backfeed

<aaronpk> s/bridgey/

<harry> Sorry guys had an email crash will be down in a sec

tantek: publishes using your feed and throttles it's publishing
... if you set it up to let anyone through, it will get shut down

<cwebber2> but I think that anyone can build these things without the help of this working group

tantek: if you do things their way, you won't get shut down

<cwebber2> it already happens

tantek: to chris's point, why are we talking about this at all?

<elf-pavlik> cwebber2++

<Loqi> cwebber2 has 17 karma

tantek: federation is completely about reaching your friends
... reaching your friends is a core user story
... we're not here to help people in their own little mono-cultures

<AnnB> or between tools, that are willing to be federated

Arnaud: part of not being shut down is not using a client with a bad name like...DestroyTwitter

eprodrom: I'm wanting to sketch out how does federation
... since we're kind of approaching our lunch hour, I can do more of this later

<Loqi> Tantekelik made 1 edit to Socialwg/2015-03-17

eprodrom: the API has a number of endpoints for doing federation
... there's an outbox feed
... I can write to that


eprodrom: there's an inbox feed that my friends generate
... there's lists of people I follow, lists of people following me, lists of replies, etc.
... main way to interact is to post to your output feed
... will do the effort of adding that item to the list of favorites
... and moving that item
... the inbox for the end user is typically read only
... but for other people on other servers it is write only
... other servers will deliver to those servers based on the content in the ActivityStream

<elf-pavlik> eprodrom, aaronpk can you compare micropub+webmention to APIs (c2s, s2s) ?

eprodrom: who should be receiving that activity
... if aaronpk posts a new note that is to eprodrom, his server will route that to his inbox
... discovery is through WebFinger and in some cases the ActivityStream
... authentication is via 2-legged OAuth
... it's basically saying, I'm aaronpk at and you are, here's a message for eprodrom
... the server deals with routing to that inbox
... there are pluses and minuses to this system

<elf-pavlik> multicast ?

eprodrom: one minus, for a big fan-out it can be repetitive
... with SMTP an email to lots of people will get delivered once
... with it'll get delivered multiple times
... there's also issues with maintaining social graphs
... it's pretty reliable
... there are some social graph scenarios that have not been figured out yet
... if cwebber2 follows eprodrom, tantek follows eprodrom, and tantek comments on eprodrom doesn't make it all the way back to cwebber2
... good news is we are able to move the content around via activitystreams
... you only get content from your friends...he doesn't have to make an authenticated request to my server
... the main reason I wanted to bring it up today is that it integrates very nicely into the API

<ben_thatmustbeme> aaronpk, if you didn't i was about to

eprodrom: it's the same API for discovering and reading from the API

<Zakim> tantek, you wanted to ask about and PuSH

<elf-pavlik> ACTION pelf to Investigate 'my client' to 'someone else server' authentication

<trackbot> Created ACTION-54 - Investigate 'my client' to 'someone else server' authentication [on Pavlik elf - due 2015-03-25].

eprodrom: there's a part that's compatible and also closely compatible with the activitystreams

tantek: I noticed that you've build support for Pubsubhubbub (PuSH) in the past
... it seems that's no longer the case
... what were your reasons for not using it

<ben_thatmustbeme> and indieweb methods seems very similar, with the exception that pushes data to other servers when commenting, while indieweb sends a mention to tell the server to pull

tantek: maybe there's something we can learn from that

eprodrom: OStatus was based on PuSH
... we were unable to (easily) do remote delivery of private content
... if you do a subscription to a single feed
... via PuSH
... then I will get all the same items as Amy would get
... if she subscribes to tantek via PuSH
... there is no authentication on part of the subscriber to say I'm eprodrom or I'm Amy
... just I do have a valid endpoint to which I want stuff delivered
... reason that's an issue is that tantek is posting private images or his location
... that would cross that federation boundary

<ben_thatmustbeme> also that means auth is on the sender instead of receiver

tantek: so there were no private notification features that you could use?

eprodrom: essentially, yes.
... there are a couple ways to hack around it
... tantek has a specific feed that is just for eprodrom
... then tantek would be responsible to publish just into that feed
... or one for friends
... or one for family
... this is my feed for friends and cwebber2

aaronpk: another way is to say your essentially putting an access token into the URL to essentially authenticate that user

eprodrom: essentially, just pushing the problem farther down the line
... what does
... there are a lot of issues with PuSH
... we tried to work around them
... it was easier to move to other relatively simple solutions
... like having the publisher have an idea to whom they want the content to go to

tantek: so more SMTP than RSS style

<bblfish> cool

eprodrom: that's a very good way to put it

<aaronpk> AdamB

AdamB: right now we're working to sync between SharePoint sites
... syncing the content between them is important

<Zakim> aaronpk, you wanted to describe federation with the indieweb stack

AdamB: eprodrom thanks for sharing that

aaronpk: with the IndieWebCamp sites that we're seeing there's essentially 2 ways we're dealing with this
... one is by posting a WebMention
... I send a very simple payload to Amy's WebMention endpoint
... that I can discover from here site
... and send a very simple payload
... Amy's site can go verify...and then do what she wants with that
... such as publishing it on here site
... it's gotten us pretty far

<elf-pavlik> rhiaro++

<Loqi> rhiaro has 34 karma

aaronpk: the way it works is by parsing the h-entry's on my site
... she can then comment on my site by publishing to here site
... this is about commenting directly on a post
... we've been experimenting with an anti-spam thing called Vouch
... dealing with the "I can comment on anything" spam stuff
... the other thing we've been experimenting with is PuSH
... which gets more into the group context
... get posts in real time
... pubsubhubbub looks like a good model
... it's only been recently that we've seen some implementations
... though hubs have been around for several years
... we're using it with microformats

<AnnB> oh! I need to go to another room to call in for the IG meeting

aaronpk: as a subscriber if I want to use it with tantek's blog, "hey I want to subscribe to you"

<elf-pavlik> action-12

<trackbot> action-12 -- Harry Halpin to Get clarification on PubSubHubbub -- due 2014-11-28 -- CLOSED


<elf-pavlik> ^ we can't use PubSubHubbub

<harry> that is finished

aaronpk: when tantek publishes, he notifies his pub that he's published something he wants others to be notfied of
... the hub then notifies the others

<AnnB> (not sure anyone will attend)

aaronpk: did I miss anything?

<harry> its useful to understand

<harry> but we can't directly use

<harry> until Google does a patent non-assert

<elf-pavlik> harry, let's just make it clear

<harry> even OWFa would be enough

<harry> likely

aaronpk: PuSH itself does not itself have authentication for distinguishing private feeds
... I'll probably use access tokens in the URL
... with IndieAuth, people can log in without pre-registering
... we may reach the same conclusion
... as eprodrom

AdamB: what we do is when you request a feed, we check who you are, then send you a specific feed

aaronpk: that's essentially what I mean by an access token for the feed
... since I'm already giving you the feed in HTML, it's not a stretch to think of doing it for a client


bblfish: I was working on notification something like pingback in 2011

<harry> there is btw no patent non-asserts on FOAF I think as well

bblfish: before LDP came out
... doing something very lightweight like the IndieWeb folks are doing
... tying into the web without asking very much
... when you authenticate with a WebID
... if people know your WebID, they can POST their stuff there to notify you
... that's very close to what eprodrom was describing
... with the semantic web, doing this in a neat way, describing the container
... having your webid point to that container
... and with a couple relations, you can get it nicely described

cwebber2: I have a number of questions
... how would you do private posts?

aaronpk: right now, my software creates an audience for a post
... there's a login box
... you can identify yourself as your domain name
... and on my site, I can show you those private posts
... there is no central thing
... you can use your reader to collect the stream for you
... we've not yet built that into the reader that my site gets your private things

<elf-pavlik> action-54

<trackbot> action-54 -- Pavlik elf to Investigate 'my client' to 'someone else server' authentication -- due 2015-03-25 -- OPEN


aaronpk: we're going to find out if we can shoehorn that into PuSH

cwebber2: some of the things that are in pump
... one side is the command language
... subscribe me to a mailing list
... or whack a goblin on the head
... some thing that's mutating state on the server
... is this specific to the server?
... or is there a shared action vocabulary?

eprodrom: with that happens through the client API
... open farm game acts as a client to your site

aaronpk: the one command language thing is syndication
... (for us)
... the client doesn't know how to post to twitter
... but my server does
... that's the one command language thing that we've done

<cwebber2> -q

harry: just so people know, we don't have patent-non-assert on PuSH and even FOAF
... we just can't use them as normative until we have that
... it'll require some hassling
... if we need that

<Zakim> tantek, you wanted to note challenges encountered with PuSH

tantek: several of us have tried to work with PuSH in various let's be upfront
... PuSH 0.3 has been around for years
... and there's really only a couple implementations
... there's Google AppSpot and Superfeedr

<bblfish> PuSH: pub sub hub hub

tantek: this is supposed to be Web-wide, but to only have 2 implementations makes me suspicious

<cwebber2> I think diaspora uses PuSH right?

tantek: on the consuming side, it's been shown to be non-trivial

<ben_thatmustbeme> PUbSubHubbub

<cwebber2> and so has friendica

aaronpk: it took me ~2 it's pretty trivial

tantek: it's been brought up as being too much of a pain to be too hard for people to implement
... in the IndieWebCamp
... it seems like it's too much work

aaronpk: the spec has holes, so it's hard to read the spec as a guide
... I took a stab at the guide to implemente it
... and I found my guide more helpful than the spec
... the hard bit's understanding the spec

eprodrom: it should be pointed out that many of the open source social projects have their own PuSH hubs

tantek: oh they do

eprodrom: things are mediated through the hubs
... to allow for huge fan outs of the deployments
... if you don't have that fan out, it's simpler
... for a lot of implementers they just implement the publisher and the hub into the same software
... even thought it's the hub part of the spec, it's the publisher that's doing it
... theirs a hub in,, diaspora

<elf-pavlik_> AFAIK diaspora uses google hub :(

eprodrom: doing a general purpose hub is a lot of work
... it's not that hard at lower limits

<AdamB> does somebody have a link for super feeder?

tantek: as a person wanting to do the publishing side
... and there being only two public hubs


tantek: that feels like a vulnerability

<AdamB> elf-pavlik++

tantek: Google doesn't actually support 0.4

<Loqi> elf-pavlik has 12 karma

tantek: and Superfeedr doesn't support all of 0.4
... I don't see rapid evolution of it with only two players

<harry> in particular, bradfitz no longer works on it

tantek: normally you need healthy competition to keep things moving

<harry> danbri1, anyone at Google still care about pubsubhubbub?

<cwebber2> elf-pavlik_: diaspora really uses google hub?

<cwebber2> all of them?

<harry> danbri1, what about patent non-asserts or something on FOAF as well?

tantek: I'm raising these issues that you know about this...despite that we're trying to make it work within the IndieWeb community

<harry> and pubsubhubbub?

<cwebber2> that's super surprising

tantek: we're looking at WebMention instead...but it's not to the point of shipping yet.

<elf-pavlik_> cwebber2, at least 2-3 years ago almos all did !!!

tantek: that's the only fallback approach I know of
... for private messages and stuff

eprodrom: something worth mentioning about OStatus

<cwebber2> elf-pavlik_: a search for 'diaspora "google hub"' on duck duck go shows no relevant results

eprodrom: and it's Atom implementation
... there was a third part call Salmon


eprodrom: which was for unsubscribed updates
... if I comment on a post that's part of a feed I'm not subscribed to
... much along the WebMention side
... tells the upstream (hence Salmon) about the post
... delivering activities between two servers
... with there's not a distinction between subscribe and unsubscribe
... they go through the same pipes

harry: just to reiterate
... one of the reasons we separated federation out
... was because of these issues
... things we thought could be safely ignored

<eprodrom> Are we wrapping for lunch?

bblfish: what's interesting is that we have two...sending message remote, but perhaps super efficient for people who've got millions of users

<AdamB> close the queue in favor of lunch?

<harry> there are privacy/security issues in a federated system, but we can do the proper reviews before going Rec-track

<aaronpk> lunch++

<Loqi> lunch has 16 karma

bblfish: and the scalability seems to be generating the need for PuSH and other tools
... but there seem to be some linked data-ish ways to get something going

<harry> well, if you don't look at the scalability then your system will likely never be adopted :)

bblfish: where the API at a bit higher level than HTTP

<ben_thatmustbeme> i think so. I ate too much at the break, now i'm not hungry

bblfish: the browser could be doing something similar

<elf-pavlik> i guess bblfish assumes action-54 already solved

<elf-pavlik> action-54

<trackbot> action-54 -- Pavlik elf to Investigate 'my client' to 'someone else server' authentication -- due 2015-03-25 -- OPEN


bblfish: which is why I'm concerned a bit that servers are doing federation
... that perhaps could be done elsewhere
... and that federation could be done at a different layer

Arnaud: there is no immediate next action about handling this distinction
... we should keep the federation deliverable in mind when we talk about the API
... as it does lead into the other

<tantek> experience has shown so far that scaling federation is hard, and anyone who has made federation work at scale (delivering / receiving 100k messages/users) is welcome to discuss how they did it (not how they *would* do it ;) )

Arnaud: they're just things we'll need to take into account as we move forward with the API
... then we'll have deiu demo the LDP implemention

tantek: I put a slot in the agenda for the demos

<bblfish> Just saying that one can do some of the "federated piece" using something that is light weight, and that does not run into scalability problems that Pubsubhubbub tries to solve, and so one should not put these out of scope of the "Social API"

tantek: for after lunch
... deiu maybe over lunch,. maybe you an connect it to user stories
... the list of user stories is linked from wiki
... anyone else who wants to demo
... can do the same
... running code...we like it

lunch time

<elf-pavlik> would someone like to take few minutes to try get audio working from my side?

<eprodrom> bblfish: can you explain exactly what you mean, and why that would be preferable to having the conceptual separation between "client-to-server" and "server-to-server", which is helping us get our work done?

<bblfish> well so the use case for server to server we mentioned was one server wants to send a message to an inbox of someone on another server right?

<tantek> bblfish: I believe that's what does right now yes

<bblfish> ok, so I can imagine a situation where my client just wants to do that directly too.

<elf-pavlik> elf-pavlik, IMO it boils down to authentication in s2s nowadays people find it easier to authenticate the 'client'

<bblfish> does not seem like the server to server is an essential part of the story

<elf-pavlik> eprodrom, ^

<elf-pavlik> or server acting as 'client' or on someone's behalf

<tantek> bblfish: experience has shown people like/build both approaches - having your client deliver directly to someone else's server and your client to your server to someone else's server

<tantek> I'm not sure I have a specific preference myself, but I do know others do one and/or the other.

<bblfish> fine tantek, but no need to invent a new protocol for client/server in that case

<elf-pavlik> tantek, how do you authenticate your client to arbitrary server?

<aaronpk> i still don't think the client-server vs server-server distinction is useful

<tantek> bblfish: indeed more we can do with fewer protocols, tends to be better

<aaronpk> servers can act as clients, so then what do you call it

<tantek> or rather, there is a burden of proof of need for more protocols

<elf-pavlik> in my 'reader' i want to 'like' 15 posts and request goes directly to servers of publishers not to my server

<bblfish> I mean we don't need a protocol "browser to client" and one "server to client" when in fact at the http layer the distinction is not needed

<melvster> server to server is just another name for saying one server is a client

<aaronpk> elf-pavlik: there is no practical difference (especially to the receiver of that like) whether the request comes from your browser or your server

<tantek> elf-pavlik: in my 'reader' / 'client' / 'app' I want to like 15 posts, and all 15 get posted to *my server* (as posts) which then webmentions the other servers

<aaronpk> and yes what tantek said

<tantek> so I suppose that's my preferred architecture

<tantek> based on my preference for data ownership of my likes

<elf-pavlik> but authentication works differently, melvster and bblfish assume it easy since they like WebID+TLS (similar to IndieCert but without intermediary service)

<tantek> having permalinks for likes on my own server is very compelling

<tantek> HTH. anyway - lunch break!

<bblfish> tantek: " having permalinks for likes on my own server is very compelling" that might just be another thing then: a good proxy api

<elf-pavlik> Bon Appétit @all

<melvster> elf-pavlik: please dont speak for me, what I like and what I dont like ... you are misrepresenting things more than is needed

<melvster> each auth system has pros and cons and uses in different scenarios

<bblfish> bon apetit

<bblfish> when are they coming back?

<elf-pavlik> melvster, if you don't use WebID+TLS (or equivalent alternative) athenticating to 50 different servers in 5 minutes makes a lot of hassle nowadays

<melvster> agenda says an hour

<rhiaro> bblfish: on the hour

<bblfish> ok. thanks

<bblfish> :-)

<melvster> elf-pavlik: im arguing for one method over another, I just request that you dont tell people what I "like" and "dont like" ... different systems are useful for different use cases

<melvster> but I can say that what I do like is to reuse w3c standards

<melvster> more specifically w3c RECs

<melvster> because most are well thought through, can be used out of the box, scale very well, and tend to put interoperability first, which is why I like LDP which came out last month, and would be interested in any REC track work this group does

<elf-pavlik> melvster, what do you think of following directions of discovering ldp:Containers and operatoins they allow?

<elf-pavlik> to reuse existing predicates (link relations)


<elf-pavlik> e.g. "hydra:property": "author"

<melvster> i do it already, ive had good experiences so far, but id like to continue testing and working on use cases

<elf-pavlik> melvster, how do i find container with things that you have authored ? e.g. using inverse of schema:author

<elf-pavlik> or container with people that you know, following foaf:knows

<elf-pavlik> or events you participated in, following schema:event

<melvster> i dont follow too schema . org closely, sorry, we have an mblog author and dct created is about all I can tell you

<elf-pavlik> melvster, let's don't get stack on from which vocab we pick terms as long as we both can understand them in conversation

<melvster> well you'll do a map reduce of all the quads you know, and extract the data, or do a sparql search

<melvster> otherwise you have to guess

<elf-pavlik> in general 1) i know your URI identyfing you 2) i know predicate i want to follow e.g. foaf:knows 3) i want to get have container of all the things which relate to you via this predicate

<elf-pavlik> have you looked at ?

<melvster> a bit, i use hydra for other things tho

<melvster> ldp container suits my uses

<elf-pavlik> and let's forget sparql for this conversation if you don't mind

<melvster> i dont mind

<elf-pavlik> how do you discover relevant containers?

<elf-pavlik> container of 'my friendss' or 'events i participate(d) in' or 'my wishlist'

<melvster> discovery always works the same way in any context

<elf-pavlik> foaf:knows, schema:event, gr:seeks ^

<melvster> 1) follow your nose (preferred) 2) well known locations (or hard coding) -- specs are part of this 3) search ...

<melvster> you will use the right approach for each job, so generally a probe sequence of follow your nose, if that fails you look in well known places (this is much more common than thought), then lastly you go to the web and issue a query

<elf-pavlik> AFAIK currently following your nose to a *container* doesn't work that well, you can't use predicate directly because of rdfs:range (doesn't include container or rather implies that container has some particualar type)(

<melvster> but im moving more towards streaming data

<elf-pavlik> deiu, can you read last 4 lines? how do i *discover* container of all my friends, events i participated in, things i gr:seek

<elf-pavlik> so far I find hydra:collection the most interesting

<melvster> query the web (since im not allow to say sp****)

<elf-pavlik> deiu, my brainstorming

<melvster> just put all your data in a single container

<elf-pavlik> melvster, do you really think your comments help? (not questioning that they make sense in some way...)

<melvster> elf-pavlik: be nice

<elf-pavlik> melvster, happy hacking!

<deiu> elf-pavlik: I don’t understand your problem

<deiu> You follow links, that’s all

<elf-pavlik> - me

<elf-pavlik> i want to follow in inverse direction schema:author and get container of all the things i authored

<elf-pavlik> this one tries to have also container of things i authored of particular type

<deiu> the way I do it is like this:

<elf-pavlik> hydra:type doens't exist, just playing with idea

<deiu> I have a triple <#me> :storageServer <server>, and if you dereference <server>, you get a generic LDP container

<deiu> all my apps use that link to find out where they can write/read data

<deiu> if the doesn’t find a “common” container for it’s type of data, it creates a new one

<elf-pavlik> deiu, what if i want to read list of 2000ppl linked to you via foaf:knows ?

<Loqi> Asambra made 1 edit to Socialwg/2015-03-17

<elf-pavlik> this page explains how to 'find' collection containing it

<elf-pavlik> following already existing predicates but not messing with their rdfs:range

<deiu> I’m not doing any owl reasoning

<elf-pavlik> but i can't do

<elf-pavlik> <#me> foaf:knows [ a ldp:Container ] .

<elf-pavlik> or maybe sholdn't ?

<deiu> Don’t do that

<deiu> I really doubt you understand LDP at this point

<elf-pavlik> deiu++

<Loqi> deiu has 1 karma

<deiu> You should take a look at the primer maybe:

<melvster> elf-pavlik: how do you discover who has linked to your homepage?

<elf-pavlik> < > ldp:DirectContainer;

<elf-pavlik> ldp:membershipResource <#it>;

<elf-pavlik> ldp:hasMemberRelation bt:hasBug;

<elf-pavlik> <#it> a bt:Product;

<melvster> you are mixing up forward search and reverse search

<melvster> for forward search you follow a link, for reverse search you need an index

<elf-pavlik> how do i link from <#it> to that container

<elf-pavlik> hmmm... i could just use inverse of ldp:membershipResource

<elf-pavlik> { "@id": "#it", "@reverse": { "ldp:membershipResource": { "@type": "ldp:DirectContainer" } }

<elf-pavlik> i guess i just looked for using inverse of ldp:membershipResource

<elf-pavlik> just with this one I don't see a way to use ldp:hasMemberRelation and use inverse of that relation

<elf-pavlik> as in

<melvster> sure!

<melvster> i didnt really anticipate it being ready to demo yet, but we can give it a try! :)

<sandro> scribe: sandro

<scribe> scribenick: sandro

<deiu> yeah, no worries, the game I’ll also demo is even worse :)

<deiu> i.e. very alpha

<elf-pavlik> melvster, i look how to avoid 'fixed paths' as in

<elf-pavlik> http://<hostname>/api/user/<nickname>/followers

<elf-pavlik> and instead reuse existing predicates e.g.

<Loqi> Eprodrom made 1 edit to Socialwg/2015-03-17

<elf-pavlik> action-44

<trackbot> action-44 -- Pavlik elf to Collection - compare AS2 design with LDP, Hydra, etc. -- due 2015-03-17 -- OPEN


<harry> my 50,000 foot take would be

<harry> 1) microformats do POST with url form encoding and GET with HTML

<harry> 2) does with JSON

<elf-pavlik> using ldp:Container instead of as:Collection would give a first step to align 'social syntax' and 'social api'

<aaronpk> elf-pavlik: can you see the screen?

<aaronpk> (there's not a lot on it right now)

<elf-pavlik> aaronpk, yes thx!

<harry> 3) LD and does PUT/GET with RDF (including JSON-LD) with HTTP/POST

evan: yes, pump is AS1 JSON

harry: so at a high level, there's a strong similarity between ldp and

evan: and if moves to AS2 as expected, they will be even more similar

Arnaud: clarification about LDP. LDP is general purpose. But you have to build more.

<eprodrom> elf-pavlik: I agree about containers and collections

<elf-pavlik> eprodrom, thx!

<harry> SOLID vs. PUSH

<harry> :)

<eprodrom> SoLiD

<wseltzer> sandro: I was trying over lunch to come up with a name, Social Linked Data, or SOLID

<aaronpk> only a couple letters off from "silo"

<rhiaro> puns++

<Loqi> puns has 3 karma

<eprodrom> !!!

tantek: the bit that's it's not exactly LDP is important. "Just have to build upon it" is *the* hard problem!
... no matter how many times someone CLAIMS it's easy, none of those claims have merit until there's running ccode and demos

deiu: We're using LDP as a very basic way of writing data on the web.
... (I'm both MIT research and W3C, working with Tim and Sandro)
... Building linked data backends and apps

<Loqi> Eprodrom made 1 edit to Socialwg/2015-03-17

deiu: We're using LDP as a basic way for writing data on the web. It's a standard way of writing. We used to have POSTs and PUTs but it wasn't standard enough.

<wseltzer> sandro: it's not just "post to create a new URL," but also a way to get back to those resources

<bblfish> when did you start?

deiu: there's more here than just LDP. We also use WebID for identifying users,

<harry> remember you can separate WebID = URL for person from TLS client certs as authentication.

deiu: ... and for access control, per resource

<bblfish> thnx

deiu: first demo, from one of our colaborators, at QCRI, Maged Zereba

<elf-pavlik> WebID != WebID+TLS

deiu: ToDoApp (cf todomvc)
... App gets your URL from your login process, finds your storage space

<harry> on some level, this is very similar to Unhosted

deiu: you can pick a different storage space, found linked from your webid (URL)

<rhiaro> it is similar to unhosted, aye

<rhiaro> / remoteStorage

deiu tries to fiddle with

<bblfish> it's just a creating a piece of content user story

deiu: edits his photo on a profile editor

<wseltzer> [deiu demos a "make your profile" by changing his picture to a horse head]

<wseltzer> deiu: it can include information from multiple sources or profiles, e.g. personal, employer,

deiu: demos how different bits of user profile are stored in different resources with different access-controls
... chat app, using profile from before

<bblfish> what is the url for it?

<deiu> melvster: get ready

<elf-pavlik> just as this IRC channel

<wseltzer> sandro: does each person post to their own site, or to some thrd place

sandro: posse?

<Loqi> Eprodrom made 1 edit to Socialwg/2015-03-17

deiu: not yet, one chat room


<bblfish> which room are you in?

<melvster> there's different workflows, public and one one one chats, but it's open ended

AnnB: Where is the linked data part of this?

sandro: you can fork, and it'll still interop

deiu: it uses FOAF and SIOC

<elf-pavlik> deiu++ melvster++

<Loqi> deiu has 2 karma

deiu: it also have liking and presensce

<melvster> all data is stored on LDP of the users choice

deiu: demo

<bigbluehat> melvster: does it store in both user's choices of storage? or do you have to pick one for the chat session?

<elf-pavlik> melvster, can you post chatroom link on irc?

<rhiaro> elf-pavlik:

<melvster> bigbluehat: ill code that workflow in about a week after some testing

deiu: cimba has multiple channels, eg private

<bigbluehat> melvster: thanks!


<bblfish> Is there a channel I can go to have a conversation with Deiu?

sandro: right now that link opens with a generic data browser, but it should be more app specific

<bblfish> In his app

<AnnB> I think he already demo'd that with melvster, bblfish

cwebber2: No need to federate, because ti doesn't need to, because ti's just linking instances?

deiu: Yes

sandro: this is a place that motivated us thinking about s2s protocol, for perofmrnace
... this wont scale to following 1000s of people

<elf-pavlik> shepazu,

harry: this is like unhosted, kind of

<rhiaro> unhosted started on json-ld a while ago

<rhiaro> not sure where that went

<elf-pavlik> rhiaro, just pointed that out :)

sandro: but that's not social

<rhiaro> oh sorry elf-pavlik :p

harry: At the next f2f I'd like to see group-based

<elf-pavlik> rhiaro, I never finished setting them up with proper JSON-LD @context for various remoteStorage modules

<melvster> rhiaro: unhosted have been using json ld for years ... they were one of the first, ive talked to michiel about aligning our work and theirs, he's quite open to it

deiu: Is there an ACL which gives you permission to write data?

<rhiaro> melvster: cool

<eprodrom> That's interesting!

<elf-pavlik> melvster++

<bblfish> yes, one can have an acl to write data, and it can be for groups of users

<Loqi> melvster has 8 karma

AdamB: user story about colab across enterprise boundaries

<rhiaro> but yes, last time I did anything with unhosted/remoteStorage I hadn't figured out data sharing... although there was a microblogging app iirc

<cwebber2> deeply curious what kind of rdf processing libraries / triple storage these demos are using, though I know that's not really a protocol question

<Loqi> Tantekelik made 1 edit to Socialwg/2015-03-17

<cwebber2> rhiaro: neat :)

<elf-pavlik> rhiaro,

<shepazu> bigbluehat, for the record, it's not a "Future of the Web" conference (which is another brand), it's W3Conf, for developers, with the theme being "Future of the Web" :)... if anyone wants a WG meeting there, let me know

<elf-pavlik> but that had similar issue to one sandro pointed out with CIMBA (or as I understood it)

<bigbluehat> ah. I'll update harry's name database then ;)

<bigbluehat> shepazu: does it have a name?

<shepazu> bigbluehat, it's called W3Conf

<bblfish> spec for Web Access Control is here

<bblfish> with a picture showing how it works

deiu: shows us acl file for post_11
... read to everyone, read/write to owner
... can do lists and groups

<bigbluehat> shepazu: much thanks

deiu: additional modes
... demos acl editors

<bblfish> yes, you can have read to user or group, write to user or group, you can have read only or write only ...

sandro: like a global filesystem

<AdamB> harry, does this user story apply to your question:

evan: I just signed up, can you show me how following works

deiu... not working

deiu: demos following Melvin

evan: trash can, delete your own posts

<melvster> evan, sorry I wasnt expecting to demo this, this early, it's oriented towards those with an existing populated social graph

<melvster> but ill build a guide to walk new users through adding or importing contacts

<melvster> there will also be a people search widget at

<melvster> however adding a contact is *really* easy technically

deiu: demos calendar app, makes event, moves it to another day

<melvster> just use HTTP PATCH with INSERT DATA { friend } ... and it's done

tantek: how do you invite someone?

sandro: webmention, maybe

deiu: or an inbox resource

tantek: so I hear it's not done yet

<melvster> not done yet as far as I know

<harry> yep seems to be a pretty good match AdamB

<melvster> but would be a really nice feature

<elf-pavlik> rel="webmention" in <link> or HTTP HEAD

tantek: we've found inboxed overly complex. just using webmention works.


<bret> the webmention endpoint header is the discovery mechanism

<bblfish> collections are cheap

deiu: how is rel=webmention less work than rel=inbox ?

<bblfish> also if you have a different collection you can have different access control rules


<bblfish> for example you might want your collecetion to be write only to all other users apart from yourself

timbl: so they're punnning the inbox and the homepage

<elf-pavlik> Link: <>; rel="webmention"

<elf-pavlik> <link href="" rel="webmention" />

sandro: a webmention endpoint is a lot like an inbox

<rhiaro> webbox is called INDX now

<bret> Webmention sending can also happen with a form with a URL submission box <- aaronpk

<tantek> more here on indieweb invitations:

<bret> (dont forget that part)

timbl: webbox from southhampton

<bblfish> yes, so a webmention-endpoint is very much like an LDPC

<bblfish> you post to it, and it creates new resources

<eprodrom> bblfish: good point

<elf-pavlik> bblfish++


<Loqi> bblfish has 6 karma

tantek: we need the link-rel for static sites, etc

<elf-pavlik> on rel and following your nose without 'fixed urls'

AnnB: How does the calendar use linked data?

<bblfish> ah yes, in LDP does not require every resource to support GET, PUT, POST, DELETE. Each resource can specify in the ehader what it supports

<tantek> bblfish: that's good

<tantek> my point was that strict REST assumptions don't work for static sites

<tantek> so strict REST is a non-starter

deiu: every event has it own URI

<elf-pavlik> tantek, I don't think we need to support static websites!

<elf-pavlik> nice that IndieWeb does it but i guess we don't want to make it a requirement

elf-pavlik, sounds like an ISSUE

<tantek> elf-pavlik: we absolutely need to support static websites - as shown by people here with * URLs


<tantek> elf-pavlik: INCLUDING one of the demos by deiu!

<tantek> which used a * URL

<rhiaro> staticsites++

<Loqi> staticsites has 2 karma

<elf-pavlik> ISSUE: do we put requirement on supporting static websites?

<trackbot> Created ISSUE-24 - Do we put requirement on supporting static websites?. Please complete additional details at <>.

<bblfish> what are static web sites?

<tantek> demonstration of a decentralized event

<bret> elf-pavlik: :[

<tantek> with distributed RSVPs

<tantek> including RSVPs backfed from a POSSE silo copy of the event

<elf-pavlik> bblfish, static site generator - no content negotiation, GET only (did i get it right?)

<bret> bblfish: a website made up of plain html text files served with a generic server like apache/nginx or something else

<aaronpk> umm

deiu: explains how we're using a resource browser (called WARP) to wander the data space (aka filesystem)

<tantek> see also:

<bblfish> ah yes, that works. My demo yesterday with the FOAF explorer was just that. Most of the foaf was served simply by bog standard apache web servers

<bret> aaronpk: how do I rsvp and indicate remote participation?

<rhiaro> elf-pavlik: you could do conneg with a static site, but I don't imagine many people would want to

<bret> aaronpk: nm just add a note

<aaronpk> bret: i only recognize "yes/maybe/no" rsvps right now

<tantek> static sites are growing in popularity thanks to *

<aaronpk> but yeah just add a note

<bret> like whats the diff.... im here and i'm remote

<bblfish> that's explanation in the wiki page

deiu: shamblokus game

<melvster> just FYI: my chat app runs as a static or client side site too, FLOSS, MIT license

deiu: makes an ingognito window so he can play both players
... plays blockus
... One resource for the game, writable by each player, websocket notifications of changes

<bblfish> don't you guys have anything to do ?

<bblfish> ;-)

deiu: (this app was written by my wife, last weekend)

timbl: You could catch cheaters, with other people changing the board in the way they're not allowed to

evan: this game demo isn't exactly in scope.

<eprodrom> Well done!

deiu: that's it!

<bblfish> cool demos

eprodrom: No established mechanism way to subscribe?

sandro: cimba uses a "follows" vocab

eprodrom: did you look at AS2 for this?

deiu: this was a year ago, before AS2

<elf-pavlik> sandro, link to 'follows' vocab?

<Zakim> tantek, you wanted to demo distributed event + RSVP (added to agenda after Andrei's demos)

<elf-pavlik> deiu++ melvster++ sandro++ timbl++

<Loqi> deiu has 3 karma

<harry> deiu +1

elf-pavlik, maybe but look at what cimba writes.

<harry> Very good explanation

<elf-pavlik> ok

<melvster> this page has SIOC : has_subscriber to a blog :

Tantek demo of calendar

tantek: rsvp posse'd to facebook and others

<Loqi> Tantekelik made 1 edit to Socialwg/2015-03-17

<AnnB> and I, who do not have my own domain, tried to RSVP but could not

tantek: distributed invitations

<AnnB> (pointing out that some might not have their own domains ... e.g., my mom)

<AnnB> (or me)

tantek: event was federated via webmention, with favorites, to twitter and facebook

<akuckartz> AnnB++

<Loqi> AnnB has 12 karma

<elf-pavlik> AnnB AFAIK IndieWeb folks will ask you to get at least subdomain, but then still you may need to deal with setting up your SSL

<AnnB> (or, maybe I didn't know how to RSVP in some other manner)

<AnnB> my point is, elf-pavlik, I think it's unreasonable to expect the every person will have the interest or skill to do that

tantek: a favoriting on twitter of my rsvp turns into a mention of the event

<elf-pavlik> AnnB, I agree!

<elf-pavlik> we had this discussion on mailing list, and, MediaGoblin, Diaspora, Friendica and many other systems don't put such requirement on people

<elf-pavlik> just an IndieWeb thing

AnnB: I tried to reply but it didnt work

aaronpk: maybe something about your facebook account wasn't completely public

<elf-pavlik> AnnB++

AnnB: I love all of this, but I don't think it's reasonable for everyone to have their own domain

<Loqi> AnnB has 13 karma

tantek: no, this works with facebook just fine (modulo privacy settings)

<bret> the domain requirement is a design (and conference attendance) constraint. known provides people with these features without a domain and its not inherent in the tech

timbl: How is this a privacy issue?

<AnnB> for the record .. these guys explain that my RSVP from Facebook may not have come through due to my privacy settings in Facebook

<elf-pavlik> IndieWeb --- option --- option --- option --- Silo (F,T,G) etc.

<AnnB> in other words, nothing about me having my own domain

ben_thatmustbeme: probably doesn't have access


tantek: it also has a policy against anything that's not 100% public
... Also there are hosted options, like

<Arnaud> +q


harry: I thikn we should return to URL encoding before the end of the day

evan: After break

cwebber2: to be a mild troll here...

AnnB: (mediagoblin!)

cwebber2: federation, silos, ... is there more than one instance?

tantek: It's 100% open source, so anyone can make their own instance. So like PuSH hubs, one can make your own on your own site

cwebber2: Isn't this the same worry you had about PuSH, that there's only webmention

tantek: this is just for snowflake APIs

aaronpk: wouldn't be necessary if the silos did webmention

<ben_thatmustbeme> eprodrom++

eprodrom: I'm concerned we're spending too much time on bridges

<Loqi> eprodrom has 7 karma

tantek: But a bridge between webmention and would be awesome, and it help us understand the issues.

<cwebber2> thanks for tolerating my troll :)

timbl: bridges are great for helping understand, but they do take time

<tantek> cwebber2: not a troll at all - that was an excellent question

tantek: they're also great for outreach

<tantek> cwebber2++ for asking the hard questions

<Loqi> cwebber2 has 18 karma

Arnaud: one bridging, I understand practical need, but doesn't it defeat the premise that you're in control of your data, since you've copied the data into facebook -- now they have it, and they own that copy

tantek: Facebook could go away and you'd still have it.

eprodrom: it protects against deletion, not reading

<bret> you dont have to send a copy to facebook luckily

Arnaud: this doesn't help protect against profiling

tantek: How much is it worth to you (in terms of being profiled) to invite your facebook-only friends? That's the tradeoff each person needs to make.

<bblfish> don't worry. Just was going to say

<timbl> (Maybe could have ACL control so the brdge wil check ACL and only brionge things which have public ACLs)

<bblfish> that if we make a W3C API then Facebook can implement it, and then we won't need a proxy API

<bblfish> :-)

<akuckartz> bblfish++

<Loqi> bblfish has 7 karma

Social API

<bblfish> bblfish--

<Loqi> You can't karma yourself!

<bblfish> just checking Loqi

<akuckartz> :-)

<harry> I'm happy to modify and give them a specific time-window

<bblfish> :-)

eprodrom: Narrowed down yesterday to, indieweb, ldp/solid, ... with anyone new who comes in needs demos, evididence, etc

<bret> bblfish, i think facebook would rather bask in walled gardens

<bret> ;)

<AnnB> sadly, bret, seems to be true

<AnnB> of course that's how they make their money

eprodrom: Matrix? permalinks, screenshots

<Loqi> rhiaro has 36 karma

<tantek> permalinks++

<Loqi> permalinks has 2 karma

tantek: number of users, number of implementations

eprodrom: Another criterion is whether the new api is compatible with federation protocol
... we've talked about that a little bit.
... Good chance of merging solid and

tantek: I object since solid isn't properly defined

Arnaud: there is an ldp spec

eprodrom: Less of a chance to merge and micropub

aaronpk: I'm only wedding to form encoding until there's an argument

tantek: One could build a bridge

<bret> i would be interested in researching whats involved in a bridge

eprodrom: We could have two outputs, yes, with a bridge between them

<bret> between pump and indieweb stuffs

eprodrom: <3 <3 <3

AnnB: I applaud the point about figuring out how this would be decided
... This reminds me of the endless arguments about how to determine pricing the slips on a dock.

sandro: We need to get beyond self-interest to find the areas of mutual interest

<cwebber2> AnnB: :)

<eprodrom> elf-pavlik: at 15h EDT

<cwebber2> famous email ;)

<cwebber2> (in case you didn't know the reference)

harry: I see the conflict. But. URL encoding for POST is good. For GET, I understand the preference for microformats, but I see a large community that wants JSON
... I think those are both solvable.
... worse case you mandata both
... the difference seem big, but I think they're manageable
... there are lots of smaller differences
... matrix idea is about use cases
... and now I need to go

<elf-pavlik> videos + permalinks

tantek: matrix idea could be useful, if it had permalinks

<tantek> permalnks to posts

<tantek> of the outcome of doing the user stories

eprodrom: Next steps
... continue with matrix

<bblfish> there is a lot of noise

<Loqi> Tantekelik made 2 edits to Socialwg/2015-03-17

<KevinMarks> 4aCTXUk4.jpg

sandro: we don't have commitment from everyone to support a majority-decision choice

tantek: we don't even have that on AS2

eprodrom: As co-chair, I'd rather ship something, even if it's sometihng I don't really like

<KevinMarks> shipping nothing can be a good idea sometimes

eprodrom: We will need to make a decision at some point soon. eg by May 1st at the latest
... a little less than six weeks

tantek: I thought we'd try for more convegence

<fjh> +1 to tantek on encouraging cooperation and convergence

<AnnB> +1

tantek: let's try for more collaboration and learning

<cwebber2> +1 to convergence also

<rhiaro> +1 convergence

<bblfish> I was going to say what timbl is saying

<fjh> where it is useful

sandro: are you saying we recommend 3 stacks

timbl: no

<tantek> timbl: e.g. we had CSS and XSLT

<tantek> (meaning XSLFO)

timbl: I'd be against a sharp cutoff on dev on non-selected stacks

tantek: CSS and XSLFO were RECs
... It could be a success recommending more than one, if they have different areas of utility

<cwebber2> -0 or maybe -1 on multiple recommendations, I'd really rather avoid that direction, but +1 on convergence

<elf-pavlik> we could have on RPC based (like micropub and sockethub) and one more REST, LDP, Hydra, LDF

bblfish: That sounds reasonable. Maybe some ways to get consensus, by looking at how similarly we actually tackle a user story.

<cwebber2> I think convergence is really helpful, I agree that we probably don't have that much difference

<cwebber2> though I worry if we end up with multiple apis / federation standards we haven't solved the problem of "here's a fractured set of decentralized standards" :)

<AdamB> i share the same concerns cwebber2


<Loqi> @SocialWebWG :: three different action models out there right now:, #AS action handlers, and @w3c #Hydra. convergence would be great.

eprodrom: I'd be more comfortable putting forward two proposals that have different applications than two that are very similar and differ only in style

<tantek> elf-pavlik: who is posting on SocialWebWG?

<tantek> AFAIK the chairs do not have access to that account

<elf-pavlik> Erik

<tantek> is that documented anywhere?

eprodrom: looking for more solid ldp-based suggestion

<deiu> cwebber2: standards.png

<ben_thatmustbeme> cwebber2, I do think it moves toward getting things standardized though. If you publish 3 specs, its a lot better than everyone do their own thing. You build interconnection where needed

<elf-pavlik> tantek, see

<cwebber2> ben_thatmustbeme: :)

<cwebber2> er

<cwebber2> deiu: :)

<tantek> thanks elf-pavlik

<cwebber2> deiu++

<Loqi> deiu has 4 karma

eprodrom: looking for opportunities for ...

tantek: :) maybe make a call for FPWDs?

<melvster> +1 convergence

eprodrom: Can we make multiple competing drafts and then kill some of them?

sandro: yes

Arnaud: yes

wseltzer: turn them into NOTES...

<ben_thatmustbeme> I would love to work on eventually converging these with minor changes. we may never get there, but if we can get the specs down to a point of "here are the 2 or 3 things that we differ on but everything else is the same" i think that would make for a possible convergence

<KevinMarks> !meme two drafts enter, one draft leaves [thunderdome]

BREAK until 3:20

<Loqi> 4aC6xzCx.jpg

<ben_thatmustbeme> or you standardize a few minor options at that point

<Loqi> Tantekelik made 1 edit to Socialwg/2015-03-17

<cwebber2> for those with wrist issues

<ben_thatmustbeme> thanks for that cwebber2

<cwebber2> np ben_thatmustbeme

<AnnB> ben_thatmustbeme, yes for at least the first part of Thursday

<ben_thatmustbeme> excellent

<bblfish> hi

<bblfish> should we be in the photo?

<elf-pavlik> bblfish,

<cwebber2> bewww beww bewww

<cwebber2> elf-pavlik: :)

<tantek> I want to reiterate my proposal

<wseltzer> scribenick: wseltzer

<tantek> PROPOSAL: the WG encourage co-evolution and bridge-building across Social API candidates, instead of competition towards a date-driven selection

<elf-pavlik> +1

<cwebber2> scribe: Tsyesika

<scribe> scribenick: Tsyesika

<aaronpk> photos are uploading now... will add to the wiki when they are done!

<cwebber2> username is eprodrom

evan: harry wanted to discuss using URL templates or follow your nose discovery API

<bblfish> +1

evan: are there other items we wanted to get onto the agenda before we move forward?

tantek: I tried to collect all the additional items we didn't get to here, the floor is open for people to pick items core to our work to discuss

<elf-pavlik> tantek, evan picked one from 15.20-16.50 slot

sandro: I'd like to talk about interoperability between different formats, JSON and form encoding, etc.

<AnnB> +1 on Tantek's proposal

<rhiaro> +1

<sandro> +1

<AnnB> although also supporting Evan's point that we need to get something done sooner than later

eprodrom: One agenda item is URL templates vs follow your nose

<cwebber2> +1

<AdamB> +1

<AnnB> (ie that was the point of having a date)

<ben_thatmustbeme> +1

tantek: I'd suggest we do this one first

eprodrom: we have more from sandro discussing cross mediatypes


tantek: after follow your nose?

<bblfish> what's happening?

eprodrom: group photo - check
... harry asked us to discuss URL templates vs follow your nose
... are these concpets familiar or should i take some time to explain what we mean?

<elf-pavlik> e.g.

<elf-pavlik> has 'fixed path' http://<hostname>/api/user/<nickname>/followers

tantek: so that was my request, if we could do my proposal first

<elf-pavlik> and could reuse predicates like

<elf-pavlik> more details in quotes on

<Loqi> Tantekelik made 2 edits to Socialwg/2015-03-17

<Loqi> Eprodrom made 1 edit to Socialwg/2015-03-17

tantek: this was the propsal
... does anyone object to this?

eprodrom: I'd like to know what the meaning is from a process standpoint. Is there an expectation that we could get to three candidates to one

tantek: I think the expetation is we take multiple candidates
... having them co-evolve and influance each other greatly benefitted both of them which wasn't expected at the time

sandro: what would be nice is to use similiar language to talk about similiar features and it'll become obvious

eprodrom: I think this makes sense, we could describe an anti-pattern we be lazy and don't take on the task of making decisions

<elf-pavlik> e.g. RPC API like micropub/webmention/sockethub/ and REST API like LDP/Hydra/LDF/

eprodrom: if we're doing something because we think it's right then that's alright but if we're doing things because we don't want to make the tough decision then i'd rather we took the time to do the tough stuff

tantek: there is a complete lack of consumer participation in this WG. I feel that there is a lot to learn from each other specs
... there has been a lot of advancement in them in the last few years, take micropub which is only 2 years old. I want to continue the rapid development

Arnaud: maybe there is a compromise that can be made for now, we can revisit it later.

sandro: Publishing working multiple drafts could could bring others to the table

<sandro> sandro: and they might have strong inputs

<elf-pavlik> 2 open APIs better than 20k snowflake APIs ;)

<ben_thatmustbeme> elf-pavlik++

<Loqi> elf-pavlik has 13 karma

<elf-pavlik> can you retype?

bblfish: I could imagine a working draft which could address ping that could...

<eprodrom> PROPOSAL: the WG encourage co-evolution and bridge-building across Social API candidates, instead of competition towards a date-driven selection

i didn't catch all that sorry bblfish

<tantek> +1

<elf-pavlik> +1

<eprodrom> +1

<sandro> +1

<rhiaro> +1

<ben_thatmustbeme> +1

<aaronpk> +1

<AnnB> +1

<cwebber2> +1

<AdamB> +1

<AnnB> I think bblfish said he could imagine "micro working drafts" on specific topics

tantek: i think this is a good testimonial to this group. a lot of people outside the group don't expect us to agree on anything and because we are able to agree and colabourate

<bblfish> +1 I imagine we can build a few micro proposals for specific use cases and then find points of agreement ( such as standard vocab )

AnnB: we should write a small explanatory proposal to explain the logic of recommending 2 paths

<bblfish> then we can draw these together to build bundles of agreement

<Loqi> Tantekelik made 2 edits to Socialwg/2015-03-17

<Loqi> Rhiaro made 1 edit to Socialwg/2015-03-17

RESOLUTION: the WG encourage co-evolution and bridge-building across Social API candidates, instead of competition towards a date-driven selection

<cwebber2> is there general consensus also that the ideal world though is 1 proposal that everyone is pretty happy with over 2 proposals I assume? ;)

<AnnB> (if we do)

eprodrom: lets move to the next item which is fixed URL format vs follow your nose

<cwebber2> even if we do end up that route, which is better than some alternatives

eprodrom: this has come up a few times

tantek: can someone provide an overview

<bblfish> cwebber2: yeah I think that is understood

<elf-pavlik> e.g.

<elf-pavlik> has 'fixed path' http://<hostname>/api/user/<nickname>/followers

<tantek> definitely in favor of follow-your-nose

eprodrom: the rough idea is that you can always find your followers at /<nickname>/followers but if there was a follow your nose you would look for a link with a rel type and follow that
... most would agree there is a lot more flexable with follow your nose because you can put that where you want

<tantek> based on experience of interop across disparate systems, modularity, flexibility of webarch

sandro: you could put a high traffic one on another server

eprodrom: there are a few downsides with follow your nose, one is multiple requests

<Arnaud> 'fixed URL formats' vs. 'follow your nose' (URI opacity & URI Templates) should really be 'fixed URL formats' vs. 'follow your nose' (URI templates vs URI opacity)

eprodrom: if i request the same info over and over there is overhead, there is a request, parse, re-request
... obviously caching is important here for clients
... the second is the problem with defacto standadisation. Everytime a developer see's there is a link and will take shortcuts and notice the link is the same everytime
... and then there are problems with smaller nodes which can't implement that format
... then it becomes a defacto standard

<bblfish> is this issue in tracker?

<elf-pavlik> nope

eprodrom: for third party developmers a new follow your nose type system is going to be difficult for them
... i think harry wanted to address it, i brought it up as an issue as it's come up a few times and it's been strongly suggested we use follow your nose

<rhiaro> I don't know what I'm talking about, but what if there was a recommended URL pattern backed up by a simple discovery mechanism if you don't find it there?

eprodrom: are we unanimous on doing a disocvery, it's the way micropub and webmentions work...
... does it through webfinger discovery and it also does it through activity streams link elements
... there are links to users, replies and likes

bblfish: so the way of solving this is to show that these aren't incompatible

<aaronpk> yes

bblfish: it's difficult to get people to agree on URL patterns and they don't want to agree on it and there are URL patterns which already exist

<aaronpk> and i have to mute this one

bblfish: you're restricting where you don't need to
... and then there is obviously the efficiancy issue.

<elf-pavlik> i can just type, 3-4 lines

<AdamB> bblfish - can you type in your last part about efficiency


<bblfish> I think this can be a building block for building that

timbl: power is a way to say everything under XXX is unsuitable for children, you can make sweeping declorations

<sandro> Real link:

timbl: it was designed on putting metadata on suitability for children or licensing. I'm not so sure to turn it around backwards and say if it has certain properties

<Zakim> elf-pavlik, you wanted to discuss reusing vocab terms and clear connection between 'data syntax' and API

<elf-pavlik> instead of paths like http://<hostname>/api/user/<nickname>/followers

<elf-pavlik> we can reuse predicates like

<sandro> elf-pavlik, speak!

<aaronpk> elf-pavlik: go ahead

<elf-pavlik> but it has issue with collections/containers which hydra:Collection tries to resolve

<sandro> louder!

<sandro> nope

<sandro> no good.

<sandro> type it please, elf

<elf-pavlik> i'll just type 2 more lines

<elf-pavlik> so we can link to *collection* of followers

<Loqi> @elfpavlik :: Collections in #RDF? @LDPWG @SocialWebWG @danbri @kidehen @manusporny @jasnell

<eprodrom> Please just type it

eprodrom: please just type it

<elf-pavlik> using schema:follows (or inverse)

<elf-pavlik> reusing vocab terms (predicates) instead hardcoding paths

tantek: i'm still having difficulty understanding the problem statement

  • problem statement

<eprodrom> Thanks elf-pavlik

sandro: i agree with evan's analysis. I feel concerned all these popular APIs don't do this, i presume this is because developers have found this more complicated
... has anyone in the indiewebcamp has anyone asked about this?

<rhiaro> Don't silos do this because they don't need interop? people will just do what the api docs say?

<tilgovi> +1 rhiaro

<Arnaud> +1 to rhiaro's point

tantek: this has been so easy and developers have so little time but there are loads of libraries that they can just drop in. There has been no push back of people asking for hard coded paths

eprodrom: new social networks start all the time (secret, instergram)

<elf-pavlik> no need to parse HTML!

eprodrom: if a new social network came out and their documentation did not look like social networks which came before and instead it says to start with the discovery where the links are - I think it's unlikely they would, i think it's likely they will just put out the URL patterns and not the discovery process

<bigbluehat> discovery can happen in a Link header fwiw--then there's no HTML parsing

sandro: Hopefully they wouldn't even have to do that, they can just point to a spec and they can just point to that and say "we use that"

<bblfish> my point in full above comes in 2 parts:

<bblfish> A. Global convergence problem

<bblfish> 1. reduction of constraints allows people to get to an agreement globally

<bblfish> 2. it is very difficult to get people to agree on names of URIs ( imagine difficulty of getting japanese to agree to use « person » for a URL

<bblfish> 3. patterns create unecessary constraints

<bblfish> B. Efficiency

<bblfish> 1. if a web site wanted to do something that is efficient a site could use POWDER to build a pattern of URLS

<bblfish> that would allow sites to help navigate more quickly through this

eprodrom: I think this is the concern. I'm willing to let it go

<Zakim> timbl, you wanted to try to clarify and bund what Harry quoted me as saying

timbl: this has been put on the agenda because I said something about this

<AnnB> timbl: I want to distinguish between reading and writing

<sandro> timbl: for *reading* it's great to follow your nose

<AnnB> ... follow your nose = follow links

timbl: when you're following links, you should be following links


<sandro> timbl: if you're selling me linked-data-writing software, I don't want YOU to say where they're going, I want to be able to say I store my vcards by date, or something

<sandro> timbl: eg by name, eg by uuid

timbl: what happens on a mac. If you want to write an app and store data then you should put it under a specific path.

<sandro> timbl: on MacOS, you put stuff in a certain suggested path

<AnnB> ... geek conventions

<sandro> timbl: when it comes to writing your data, I want to be able to parameterize my software, to tell it how to make up URIs for storing stuff.

<tantek> here are also some suggestions for URL designs for data: (feel free to add / feedback inline)


<AnnB> timbl: no one in LD community has discussed that .. probly would run away screaming

<sandro> timbl: "When you store this kind of data, the URLs are going to look like this", a "footprint"

<AnnB> ... example of one technique I used

<AnnB> ... small set of rules

<sandro> timbl: the result is completely follow your nose

<eprodrom> tantek: can you load up ?

Arnaud: so I wanted to get back to the point you are raising. We're making things more complicated, it's if people understand the value of having this complication, this gives the flexability of where you can store this stuff, silos don't need this flexability
... they just say "this is where our data is you can get it there"
... but we can't adopt this position

<ben_thatmustbeme> right now we have a level of indirection... but it is non-programatic, you have to check the docs on a particular host

eprodrom: what we're trading off is simplicity for the client, familiarity for the dev. I want to make sure we're conciously trading those off as we'll have to defend that

Arnaud: there is always a trade off between flexability and complexity

eprodrom: i think for individuals and small groups where putting my API under several levels of dirs because i run several apps on my domain - this makes a lot of sense
... for cloud hosting or companies this is less of an issue because they can have a seporate domain

<ben_thatmustbeme> so you have to look up that site X stores at /users/bob you have to either know their pattern or find their documentation. We are just talking about a useful markup for it

eprodrom: a way this could work is there is always a directory tree

<bblfish> simpler for the client if the client is only limited to one server

eprodrom: there is inflexability on the server side but we trade this for flexability on the client side

<bigbluehat> bblfish++

<Loqi> bblfish has 8 karma

<bblfish> but as soon as you have friends across servers it does not work

timbl: say a generic API where the URIs could be anything, then you can imagine annotating facebook you could abitary (?)

<Zakim> tantek, you wanted to say there's also room for documenting known best practices and to also say silos break their paths with API versioning too! E.g. Twitter 1.1

<Loqi> Tantekelik made 2 edits to Socialwg/2015-03-17

<eprodrom> PROPOSED: the WG will prefer follow-your-nose architecture in the API candidates we consider


tantek: so this might be a moot point as i agree. We could document patterns.

<elf-pavlik> +1

<cwebber2> giving normative suggestions is a good idea

tantek: the second piece of info, silos break these hard coded paths frequently. Twitter iterated to 2.0 and broke all of 1.0 paths
... for a long time i was skeptical but keeping permalinks around

<bblfish> humans.txt?


<bret> Lol

<bblfish> agree with tantek

sandro: you can also do this with rel=author

<elf-pavlik> my photos, videos, audio etc. can all stay hosted on different servers and different domains! can't always reach them from path 'under' my online profile

<Zakim> elf-pavlik, you wanted to discuss data doesn't need to leave on same server/domain

<bigbluehat> <link type="text/plain" rel="author" href="http://domain/humans.txt" />

<bblfish> ( so this meeting is already being very positive )

<elf-pavlik> my photos, videos, audio etc. can all stay hosted on different servers and different domains! can't always reach them from path 'under' my online profile

<bigbluehat> sandro: ^^

<elf-pavlik> e.g.

<elf-pavlik> my account:


<elf-pavlik> my photos folder:

<elf-pavlik> can't reach it via / path

<bret> I believe google offers some support for humans.txt

<KevinMarks> for big silos we can track equivalent URL patterns - see for an earlier effort at this:

eprodrom: I think this is again for individuals and those using 3-rd party services follow your nose makes a lot of sense

<eprodrom> PROPOSAL: the WG will prefer follow-your-nose architecture in the API candidates we consider

<ben_thatmustbeme> +1

<bblfish> +1

<tantek> +1

<elf-pavlik> +1


<sandro> +1

<rhiaro> +1

<eprodrom> +1

<cwebber2> +1

<bret> +1

Arnaud: do we have any candidates which don't do this?

eprodrom: we have one i think

<AdamB> +1

tantek: webfinger also breaks this, if you're depending on webfinger you're breaking follow your nose

<bret> .well-known

<AnnB> I'm only abstaining in favor of "real" geeks' opinions

<aaronpk> +1

<aaronpk> sorry i got kicked offline

<elf-pavlik> webfinger--

<Loqi> webfinger has -2 karma

<tantek> webfinger--

tantek: based on that alone i refuse to put that on my site (webfinger)

<sandro> tantek: this is why I refuse to implement webfinger

<Loqi> webfinger has -3 karma

<bret> AnnB: your a geek face it ;)

<melvster> webfinger--

<Loqi> webfinger has -4 karma

<bigbluehat> webfinger-- bye webfinger

<Loqi> webfinger has -5 karma

RESOLVED the WG will prefer follow-your-nose architecture in the API candidates we consider

RESOLUTION: the WG will prefer follow-your-nose architecture in the API candidates we consider

<elf-pavlik> \o/

<bret> Woop progress

eprodrom: okay we were going to discuss the question is cross mediatype interoperability

<KevinMarks> what is follow-your-nose?

<melvster> KevinMarks: following links from one document to another ...

<eprodrom> KevinMarks: using discovery to find an endpoint

sandro: as i look at the different candidates. mediatypes are different syntaxes

<eprodrom> So if you want to find the list of friends of

<cwebber2> +q

<aaronpk> i don't think w3c would appreciate Loqi making wiki edits all day long

sandro: two of them are okay with JSON-LD...

tantek: microformats are also available via JSON

<elf-pavlik> see also

<KevinMarks> so XFN/FOAF style?

aaronpk: i'm pointing out parsing microformats and HTML results in a native data structure in your language

<elf-pavlik> page above links to

<elf-pavlik> and

<bret> JSON.parse() ~= mf2.parse()

<eprodrom> KevinMarks: fetch "", parse the HTML, and find the link with rel="friends"

<melvster> KevinMarks: that's one of many patterns, yes

aaronpk: parsing a JSON string could also result a native datastructure in that language

<eprodrom> KevinMarks: vs. having a fixed URL format, like "the list of friends is always at /friends"

<Loqi> Aaronpk made 1 edit to Socialwg/2015-03-17

<Loqi> Tantekelik made 1 edit to Socialwg/2015-03-17

aaronpk: in JS you shouldn't evaluate JSON directly, you should parse it

<tantek> FYI:

timbl: does microformat produce dictionaries and arrys?

<eprodrom> KevinMarks: etc.

  • arrays

<KevinMarks> so folow-your-node is code for "define some rel values" OK, got it

<eprodrom> Yes

<elf-pavlik> similar to parsing RDFa, JSON-LD or Turtle - you end up with the same graph

aaronpk: microformats can (?)

<eprodrom> I say "Discovery"

<AnnB> KevinMarks, do you mean "follow-your-nose"?

aaronpk: you can't take any JSON string and convert it to microformats

tantek: it uses a subset of JSON

<AnnB> (as opposed to "follow-your-node"?)

aaronpk: it uses objects, arrays and strings. there is no integer as there is no integer in HTML

sandro: to paraphrase: the answer to my question is people should just use a library to parse microfromats just like people use a library to parse JSON

<elf-pavlik> i started tiny basics on mf json 2 mf json-ld script

tantek: multiple parsing libraries exist


<eprodrom> AnnB: it's a good typo

aaronpk: the parser does not need to change when multiple vocabs are added/changes

<sandro> aaronpk: microformats parsers are generic, fixed in 2009

<eprodrom> Grrr

cwebber2: i might be confused but if you're getting HTML and parsing the response that's one thing.
... JSON is already nested, it's not one level deep - one of my cencerns is just having strings... it's useful to have the nesting

aaronpk: not all parsers support nesting

<rhiaro> uris++

<Loqi> uris has 1 karma

aaronpk: there is a well established existing stablished pattern for dealing with nesting but a better solution is to avoid nesting

<elf-pavlik> timbl, i started a bit on conversion script

aaronpk: you point to things rather than nesting the objects

<elf-pavlik> to get something as in

<eprodrom> +1

timbl: if in doubt stick a URL in it

<Zakim> sandro, you wanted to ask if there are also generic microformats serializers

<eprodrom> Premature ack

Arnaud: there are people who would disagree with the requirement that everything has to be named

<sandro> blank nodes are a controversy in RDF -- they allow nesting, reference without giving a URL to the thing being referred to

<cwebber2> +q

sandro: are there generic microformat serialisers as well?

aaronpk: no but there could be

tantek: it's a lossy conversion because HTML is richer than JSON

<elf-pavlik> issue for RDFa serializer in JS

sandro: do you know how much of JSON is...
... you can't do numbers

<elf-pavlik> similar issue as microformats html serializer

<Zakim> timbl, you wanted to ask whether there is a common jsonld context which could be written or had been written to turn parsed microformat into RDF model.

<sandro> sandro: can you write a generic JSON->microformats serializer?

<sandro> aaronpk: yes, for the right subset of JSON, but I don't think anyone's done it.

timbl: i've found i'm moving stuff to behing typed. Tables and things will do more smart things if they're type aware like sorting
... there are arguments for having things typed

tantek: you need a microparser for datetime in microformats - though i think that's the only one
... it's an interesting datatype which is used a lot

<cwebber2> {"actor": {"image": {"@type": "Link", "href": "", "mediaType": "image/jpeg", "width": 250, "height": 250}}}


cwebber2: i'm pasing into the chat an example of something in the AS spec
... it's several nested layers deep. you might structor this different but this happens a lot in a lot of APIs, you can have an array but what about an associated array

aaronpk: you can do that with form-encode, it's just not part of the form-encoding spec

<eprodrom> actor[image][width] = 250

<elf-pavlik> cwebber2, we have discussion about it on public-linked-json list

<elf-pavlik> let me find a link

eprodrom: you can do this (pasted in)

<eprodrom> actor[image][width]=250&actor[image][height]=250

eprodrom: that's how you can do it in form-encoding

tantek: the example you gave is something you might get form an AS output but as something you submit, a server can't trust those attributes

<elf-pavlik> cwebber2, re associative arrays in JSON-LD

tantek: what is the size and mimetype of the image
... you just have a href to the image in microformats because the server has to verify that data
... so it should figure it out itself

<elf-pavlik> issue-14

<trackbot> issue-14 -- as:Link adds a lot of complexity, if we keep it we need to clarify consequences of using it instead of as:Object -- open


cwebber2: sure but i just pulled something nested out out of the spec

eprodrom: we've been talking about this, it came up yesterday. We do have microformats conversions of all the examples in the AS 2.0 spec

<elf-pavlik> eprodrom++

<Loqi> eprodrom has 8 karma

eprodrom: is it possible/reasnable to define a machine translatable (?) to go between those

aaronpk: is it going to depend on the vocab
... are we talking about the transformation of the data structure?

<elf-pavlik> you can't have that in microformats

<tantek> I'm still waiting for my fixes to examples 1-2 to be accepted:

<elf-pavlik> you could convert mf -> RDF but not the other way

<tantek> so we don't have valid microformats examples for all examples in the spec

<tantek> we are in the process of making them

eprodrom: we're talking about something like what for example a like activity might look like

<elf-pavlik> tantek, can you have this one in mf?

<elf-pavlik> behind serializations one also needs to map vocabs

tantek: I'm not sure if it is possible to generate good machine output automatically so i'm keeping track of the changes i'm making manually so someone can come along later can try and automate it

<elf-pavlik> +1 ISSUE

<aaronpk> elf-pavlik: yes

eprodrom: so maybe we leave this as an issue? machine translation between microformats and AS 2.0?

<aaronpk> except i don't know what Place vs gr:location means

eprodrom: we're 10 minutes to the hour

<aaronpk> but the "type" property is always an array

tantek: what's your goal sandro

sandro: are we going to pull this off with one syntax and if not how painful will it be to support multiple formats

<elf-pavlik> one can use microformats vocab with JSON-LD

<Loqi> Tantekelik made 1 edit to Socialwg/2015-03-17

<bblfish> we don't just have two syntaxes, we have json-ld, rdfa, turtle, rdf/xml

sandro: i think it's a nonstater with microformats. I think the web development community in general is addicted to JSON

<AdamB> does having more than one syntax increase the complexity enough to hinder adoption ?

tantek: there is a JSON output for microformat as that's what people are asking for and we can publish others in the future

<elf-pavlik> RDFa++

<Loqi> RDFa has 1 karma

sandro: it would be nice to have one syntax we publish on the web that everyone can read

<elf-pavlik> action-34

<trackbot> action-34 -- Pavlik elf to add explaination to the spec about multiple serializations used in examples -- due 2015-02-10 -- PENDINGREVIEW


<bblfish> how does a parser decide to parse something as rdfa or microformats?

cwebber2: part of the goal of this WG is to try and smooth this out - it's part of the reason i signed up

tantek: it's something that has been tried for years and i don't think this group will solve it

<ben_thatmustbeme> did we lose track of microformats vs micropub?

eprodrom: we have two proposals for a social API, possibly three:

<ben_thatmustbeme> seemed like we jumped between them

eprodrom: 1) is on linked data platform
... 2) one is on AS 1.0 which is just JSON (not JSON-LD)
... 3) micropub which is based on form-encoding and microformats
... so the question has come up can we resolve those disparities

<ben_thatmustbeme> once form posting directly to json begins working, I think the form encoding method can go away

eprodrom: so we've logged it as an issue and the answer is still to come

<sandro> issue: What syntax is (syntaxes are) to be used in the social API (eg microformats vs json-ld; form-encoding vs json-ld)

<trackbot> Created ISSUE-25 - What syntax is (syntaxes are) to be used in the social api (eg microformats vs json-ld; form-encoding vs json-ld). Please complete additional details at <>.

tantek: the market is inventing their own, the dominant players can't agree. The problem is getting worse not better


tantek: twitter cards, facebooks is kind of like RDFa but not really

<melvster> facebook support JSON and turtle

eprodrom: can we take the last 5 or 10 minutes to wrap up
... first of all we had a proposal to do a group dinner tonight

<aaronpk> group photo is posted!

<rhiaro> aaronpk++

<Loqi> aaronpk has 747 karma

<bblfish> claps

<eprodrom> bravo and thanks all

<eprodrom> trackbot, end meeting

<wseltzer> Thsaks to all for participating, and especially the scribes!