oshepherdI had to apologise to an Apple store employee once for turning up 1 hour late because I'd dared to use Microsoft software with their ics file...
wilkieevanpro: toward the end of our meeting we got stuck on what the next steps would be. we should come up with a strategy for what our next steps would be and come up with what a working draft for social API would be.
wilkieevanpro: next, once we have a list of APIs considered social APIs, we could break up those APIs in to blocks: what is about content posting, social graph, etc. see if there are areas of functionality in those APIs we haven't talked about yet.
tantekq+ to ask about what about existing *interoperably implemented* open APIs that satisfy many of the same use-cases? E.g. Micropub http://indiewebcamp.com/micropub
Zakimtantek, you wanted to ask about what about existing *interoperably implemented* open APIs that satisfy many of the same use-cases? E.g. Micropub http://indiewebcamp.com/micropub
wilkietantek: while I agree with the approach of looking at proprietary, previous social-like APIs I think we've made much more progress in the state of the art than just that. We should at least look at what Social APIs we have today that interop... open APIs and see what cases they solve already.
wilkietantek: instead of reinventing everything from proprietary building blocks. the strongest one I can think of is indiepub. which has many implementations and 8 clients supporting it which is a great deal of interop.
wilkiebblfish: coming from an architecture point of view, I should be able to follow links without worrying much about the services underneath and do so with minimal amount of sync between services. absolute minimum.
tantekq+ to say APIs are not just a matter of vocabularies, until you've built support yourself, you cannot make any such assertion. Building is the only way of uncovering what's actually needed.
wilkiebblfish: I think cutting things into blocks is a good exercise. the trick is to be is to see can one of these and look at them and find limitations to them based on implementations, or maybe we see, with creativity, we can solve generic problems in a simple manner.
tantekif "can solve generic problems in a simple manner", then demonstrate proof of that by simply solving the generic problem with your own website/client implementations and document them https://www.w3.org/wiki/Socialwg/Social_API_candidates
wilkieevanpro: I think being able to say "this is what we are trying to do. get these systems (micropub, etc) working on a set of requirements." is a great way to go.
Zakimtantek, you wanted to say APIs are not just a matter of vocabularies, until you've built support yourself, you cannot make any such assertion. Building is the only way of
wilkieharry: I'm happy to have hydra added as a candidate. I tend to agree with evanpro and other folks that we could start with something simple that looks like a HTTP API and moving out for next-gen APIs. I would focus on simple and move up.
bblfishSo just to write out what I said earlier: "starting off with the notion of a distributed social web one major constraint is that one should be able to follow links from page to page, jumping between servers, that may never have heard of each other until a user made a link between them, and so yet a software client has to be able from this to be able to work out what he has to do to allow a certain action to take place. This constraint is very s
wilkieevanpro: (wrt tantek's question) let me link here that we would have proposals that would link to Social API candidates and we would make a decision as a group.
wilkiecwebber2: as I wrote to the list, I wrote about having concerns about how there are many groups implementing federation. it would be best to use this group to consolidate some of that.
wilkiecwebber2: I reached out to Diaspora. one dev has submitted to the WG and is interested in representing Diaspora. doesn't work on federation presently, but is interested in it.
wilkiecwebber2: mon-o(?) is also interested in working with us. there are some doubt about how much they can dedicate to it. maybe it is better to spend energy on last-gen federation, but has applied for WG.
wilkiecwebber2: I reached out to other groups as well. tent.io seems skeptical. response I got was "we think we is to way too early to decide, and it is better to implement many protocols and let industry decide. we want to do our own thing"
tantekcwebber2, to be clear, selfdogfood is not just dogfood (run the software themselves), but the *self* aspect is about using it on their primary identity on the web.
wilkieevanpro: I added an issue about github and w3c tracker. I noticed we are tracking issues in both places. I want to make sure that we are ok with this process.
wilkieevanpro: if we use github to track issues on documents and w3c tracker for general issues/actions that makes sense, but I wanted to make a point to clarify anything wrong.
tantekhey MarkCrawford - would it be ok to ask you as IG chair to reach out to Annotation WG to get use-cases from them and document them so that we make sure WG develops building blocks that Annotation WG can use?
wilkiejasnell: what I have done in a proposed update to the draft is a number of edits where I took the natural language value out and depend on JSON-LD mechanisms for that functionality
wilkiejasnell: the change is basically that the current spec doesn't work properly. the current version fixes that. it's an incremental step that doesn't please everybody, but is a good step.
wilkiejasnell: I understand some parts are still controversial. but merging them into the editors draft is not marking them resolved, just giving us a base to work from.
wilkieevanpro: I want to make sure that the people involved in this discussion are ok with that. which means we are reviewing the editor's draft making sure we are addressing these issues and see next week if these are still open.
wilkiedret: so, I was trying to start to compile a list of the vocabularities people are using with AS1. evanpro is the poster-child by creating a list for pump.io, so it would be great if others did that as well.
wilkiedret: implementers: can we get something similar to what evanpro has for other implementations? so we can better understand what people are doing so far in order to develop a base vocab for AS2
wilkieelf-pavlik: I would like to take time to clarify that we may need to coordinate vocab differences and how we or others may have to extend to support things.
wilkieevanpro: the work that eric and james is doing is good. not sure where we should go with that. wrt vocabs, do we put them in the social API or do we address it elsewhere.
wilkietantek: we have a good start on that. we have a document (linked above) that shows you how if you have a consumer for AS how to be a consumer of microformats as well and how to model them. this is a great step.
wilkietantek: it would be nice to see if there are AS consumers today that would take a look at this document and see if it makes sense to them. we are looking for feedback.
wilkieevanpro: so it is 2:00. I think we have an open question to talk about vocabularies. maybe we can put that on the agenda for next week and continue discussion on the mailing list.
ZakimAs of this point the attendees have been jasnell, tantek, evanpro, oshepherd, elf-pavlik, rhiaro, Arnaud, bblfish, wilkie, cwebber2, +1.541.410.aaaa, dret, Sandro, Shane, hhalpin,
ZakimAs of this point the attendees have been jasnell, tantek, evanpro, oshepherd, elf-pavlik, rhiaro, Arnaud, bblfish, wilkie, cwebber2, +1.541.410.aaaa, dret, Sandro, Shane, hhalpin,
tantekROFL: "I think it's really unfortunate that people are building platforms on top of platforms on top of platforms, but I guess we'll all figure it out someday."
evanproelf-pavlik: I'd be happy to see you, personally, make decisions about how you're going to spend your time on social interop, especially if you'd like to work on some early experiments
tantekelf-pavlik: and if you want to more generically discuss RDFa/microformats interop, beyond just personal/s���2l site stuff, definitely drop into #microformats IRC on Freenode
oshepherdSo tantek, what are your thoughts on dropping the "post" verb from the AS spec? it would bring AS and h-entry closer into alignment, and also remove a pain point with AS1 as a social protocol (you reply to the object, but the recipients are associated with the post activity)
wilkieoh right, there isn't anything in evanpro's social API list about identity or discovery. that is beyond the scope of what we are looking at right now?
oshepherdtantek: So I think there is much merit to Activities (both for stateful things - like follow/unfollow) - but I think removing the "Post" and probably also "Share" activities is valuable
oshepherdI see comment as "minor" - subsiduary to the original post itself, maybe sometimes 'hidden' from your feed (to avoid bombarding you with people's conversations you aren't interested in), while "repost/share" is "major" - same kind of importance to posting new content of your own
tantekoshepherd: do you have documentation of where this is a problem? re: "Everything in your feed is an activity" is seductvely attractive and yet in practice wrong
oshepherdtantek: So the big one is that, for pump.io the recipients of the post activity that creates your object control the accessibility of that object. If you want to reply to an object, you need to have seen that activity, else your server doesn't know who to address your response to
tantekoshepherd: indeed, a lot of us in the indieweb community have come to a similar conclusion: having posts (h-entry s) all (re-)use common properties is important from the perspective of making sure readers know what to do with them.
oshepherdcurses Yammer for doing weird things (like notifying me of "private messages" which are part of a conversation). Wait, this is just Yammer being Yammer
oshepherdOoh, Microsoft just patched into all current Windows versions support for the TLS 1.2 cipher suites TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (plus non DHE versions of the previous nobody should care about)
wilkietantek: no problem. the stuff I'm working on is mostly 'ok pull this activity from this place. figure out what it is. ok, now you can call 'to_html' or 'to_json' or w/e and get microformated html partial or AS1/2 or w/e' I'm very interested in abstracting out for interop, so this is immensely useful.