social web (16 out of 97)

8th Social WG F2F Summary

This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!

We met at MIT in Cambridge, MA, on the 17th and 18th of November. See also day 1 minutes and day 2 minutes.

tl;dr

Everything is progressing. Naming things is hard. We need your implementations please or features may be dropped from some specs. We hope to extend by 6 months, not so we all make more work to do, but just so that the newest spec has time to make it to rec given process timing requirements. We're transitioning any other work into a CG.

Community Group

The Social Web Incubator Community Group, should be pronounced swi-kig, but by the end of the meeting everyone had taken to calling it swish. I think it was Evan's fault. Anyway it's live, and is where we'll continue to develop on top of the things we started in the WG, as well as think about how to tackle things we haven't got to yet. Aaron and Chris are chairing it, and plan for discussion to take place primarily on github and IRC, with mailing lists for broadcast only. You should join.

The spec formally known as PubSubHubbub

At the last face-to-face we renamed PubSubHubbub to PubSub. We subsequently realised this is too generic a term for quite a specific spec, and as a result is hard to search the Web for, and hard to find/name libraries and packages for. Renaming it again took the better part of a month. Heh. A few weeks ago we developed a fairly long shortlist on the wiki, listing pros and cons, and a few people voted and left their rationale. On day one of this face-to-face, we ruled out every single one of those suggestions, and came up with three new ones (WebSub, WebFollow and WebSubscribe).



We slept on it, and just before lunch of day 2, voted between these three. WebSub won. I like it for its closeness to PubSub; WebFollow is a good name for a user-facing feature that implements the WebSub protocol. Then we proceeded to brainstorm more names in the google doc, progressively making the font smaller and introducing columns so we could see them all at once.



In less important news, we added Aaron as a coeditor of the WebSub spec, resolved a bunch of issues, and there's an updated working draft up.

ActivityStreams 2.0

We decided to go ahead with a new CR for ActivityStreams 2.0. Though it's frustrating to increase the time to exit, it's also not infeasible that getting implementation reports which sufficiently cover all features will take another month anyway. Plus, this extra time ensures that the ActivityPub implementations will make it into AS2 implementation reports.

So we have a bunch of changes to AS2 since we entered CR, although none of them affect implementations or are technically normative changes, which is why we could get away without restarting CR if necessary. But we decided updating the spec with these changes (mostly editorial, clarifications, etc, which do not change the intent of the spec) is important enough not to save them all for the PR publication. Personally I think we should publish a version with the new wording around name and summary (a plaintext summary for all objects is required in the absence of name) as soon as possible.

Another useful clarification is explicitly stating that the value of the @context key may be a plaintext string, an array, or an object. We added examples of each of these, so it's clear for consumers what to look for. This is particularly important for making sure implementations which include extensions - for which the @context is necessarily an array or an object - are not completely dropped on the floor by consumers. Consumers can of course ignore extension properties they don't understand, but they should not ignore standard AS2 properties just because there are extensions alongside it.

This also means that it's possible to use the JSON-LD @language construct properly (inside the @context object) to set the base language for a whole AS2 object. As there are other ways to set the language, for individual objects or for specific values, setting the @language is not required. Further, you should not set a language if you don't actually know what it is. And we haven't dumped language tags in all of the examples in the spec, in order to avoid people copying and pasting the examples without updating the language tags we use. Apparently this phenomenon is seen all over the Web, with EN language markers alongisde text that is most certainly not EN.

Other CRs

We skimmed through a few issues for each of Micropub, LDN and ActivityPub, and checked in on how test suites and implementation reports are doing. The editors (Aaron, Sarven, and Chris respectively) are working exceptionally hard on building the test suites and chasing implementors. They are all at various stages of progress, and we know we have at least some implementations of some features of each.

• Micropub: Tests, Implementation reports
• LDN: Tests, Implementation reports
• ActivityPub: Tests, Implementation reports

Extension

The Working Group's charter expires at the end of this year. Due to minimum time constraints on various parts of the publication process, as WebSub was late to join the WG we need until at least April to take it through to a recommendation, and that's with absolutely nothing going wrong. We were aiming, obviously, for all of our other specs to be wrapped up before the various December holidays, but it'd be tight. Adding buffer time for unexpected issues, and editors-not-having-to-make-themselves-ill-with-allnighters time, we figured they'll be exiting CR in January or early February at the latest. So we expect to get an extension of 6 months, and reduce our telecon time to monthly after January. The extra time on top of April means we won't need to freak out if for any reason WebSub has to have a second CR. This also overlaps with the opening of the Community Group, so it should help with the transition.

Implementations

An extra shoutout to anyone who is thinking of or starting to implement any part of any of our specs! Please let us know, either by filing implementation reports (even partial ones are helpful) or pinging us on IRC (#social) or the mailing list so we know to chase you at some point in the future. If you don't want a feature of a spec to be dropped, ie. because you want to use it, we have to prove it has been implemented. If possible, don't wait around for us to exit CR, because we need your implementations to make it that far.

🏷 Sarven Capadisli https://aaronpk.com https://dustycloud.org aaronpk activitypub activitystreams as2 csarven cwebber evanpro julien ldn micropub phd pubsub pubsubhubbub sandro social web protocols social web socialwg standards swicg tantek w3c websub

Thu 24th of November 2016 at 8:49pm (-05:00)

Post created with https://rhiaro.co.uk/sloph

Decentralisation considered harmful

As I work - on writing standards, writing code, studying centralised and decentralised systems - and as I read the news and watch events unfold around me, bubbling away under the surface is always an unease. What if we're making it worse? We all have blind spots, limited experiences. And especially so since many of us working on decentralisting the Web are not amongst those who would benefit most from the purported advantages. Some of us have been working (or watching) in this space for years, decades, longer than the Web. But more of us, an only ever increasing number, have not. We are privileged, we are nerds, most of us don't have all that much experience, and we do not know best. We've jumped on this decentralisation thing as a solution to lots of global problems.

Towards the end of last week, Tantek prompted me to actually articulate some of what were previously just subconscious discomfort. How are the decentralised technologies we're working on going to make people more vulnerable?

Smaller attack surfaces: Large centralised systems have robust network architectures; lots of money and expertise to keep things running even if under attack (except when someone uses all of the Web-enabled kettles to DDOS them, but that aside). Many decentralised architectures imagine smaller 'pods' which federate. It's possible many of these servers will be run by volunteers, hobbyists, or small/poor organisations, and could be easily knocked over and kept down by malicious actors.

Quieter takedowns: We want it to be easier for small communities, perhaps vulnerable minorities, to create safe spaces in their own corner of the Web, and to be able to keep out those who jeopardise that. If these communities are 'disappeared' (perhaps made easier by the previous point) the rest of the Web might not notice until it's too late.

Illusion of control: We promote decentralisation as a way to control who has access to your personal/social data, and to be able to move it somewhere else if you want. But a key part of decentralisation is federation, or enabling access to your data by other systems, ie. so that you and your friends can use a different applications for the same thing, without that getting in the way of your interactions. This involves open data formats and standard APIs and likely complex access control setups. Most people tell me they can't get a handle on their Facebook privacy settings, and these are for a single unified system. Just because you could move your data to a different service, doesn't mean it's safe where it is.

Illusion of control 2: Normies look at me like I'm nuts when they find out I share more about myself on my personal website than they do on social media. I tell them I know exactly what I'm sharing, rather than having it slurped up by algorithms which monitor everything they click or hover over. My explicit sharing is greater, but my implicit sharing is reduced. Or so I think. Related to the previous point, my data is all public and nicely marked up to be machine readable. The confidence I have about the fact that I have to jump through inconvenient hoops of my own making to get it online is dangerous. If social media has normalised dangerous oversharing, and the general populace is starting to clock the 'dangerous' part, then decentralised social media runs the risk of convincing people their oversharing is 'safe' again, setting us back a decade.

The filter bubble: The easier we make it for people to avoid abuse online (just imagine for half a second that the decentralisation efforts are even close to solving this, k?), the easier we make it for people to filter out diverse points of view. The first thing I noticed when Twitter introduced its recent phrase filtering thing was a bunch of privileged liberals screaming about the filter bubble and completely missing the point. But anyway. If this is an either/or we're in trouble.

This is doubtless just the beginning of a very long list, and there are others thinking/writing about this as well. I'll update this post to list other articles as I come across them.

🏷 http://tantek.com decentralisation indieweb phd politics silos social media social web socialwg tantek web

Mon 21st of November 2016 at 2:20pm (-05:00)

Last modified: Mon 21st of November 2016 at 2:20pm (-05:00)

Post created with https://rhiaro.co.uk/sloph

Tuesday the 8th of November 2016 at 10:01pm (+09:00)

+ Recogito annotation platform

Amy added http://recogito.pelagios.org/rhiaro to https://rhiaro.co.uk/bookmarks/

🏷 annotation linked data linked research rdf recogito semantic web social web

Decentralising the Social Web in Tokyo

This is what I talked about at the W3C TAG developer summit in Tokyo tonight.

東京で2016年11月3日にて開催されたW3C TAGデベロッパー・サミットにて話した内容となります。

I am one of the staff contacts for the W3C Social Web WG. I also co-edit a couple of specs in the group, and procrastinate from finishing my PhD thesis by implementing the group's specs as part of my own website.

まずは自己紹介から、 W3C Social Webワーキンググループのコンタクトを務めています。また、そのワーキンググループにていくつかの仕様についても共同編集者をしてたりもします。そのグループの仕様を自分のサイトへの実装がPhDの論文がなかなか終わらない理由だったりします。



I'm a strong believer in owning your online presence and social data on the Web. What this means (to me) is: making data accessible through a URL that you have authority over - either you own it and host it yourself, or someone you trust does. It also means having control and choice over how and when you express yourself; working against censorship and being free to share as much - or as little - about yourself as you want. This is particularly important when we think about a how social networking works today. Big systems like twitter and facebook - silos - are hoarding the data, and creative, expressive content, and livelihoods, of millions of people. And they're mining it and using it in ways that most people are completely unaware of. If twitter goes down tomorrow - and it could, they just shut down Vine - what happens to your history and interactions? We have this huge hoard of collective digital history that we, as societies, have aggregated over the last decade, and we just gave it right up. The culture of a generation is completely out of the hands of the people who created it, and who it's important to. This could disappear at the whim of an investor, or a glitch in a data center.

私は自分自身のオンラインにおけるプレゼンスとソーシャル・データを所有することについて、強い信念を持っています。(自分にとって)どういう意味を持つか、というと、自分がオーソリティを持っている(たとえば自分自身が所有しているか、あるいは自分が信頼する誰かが所有しているような)URLからデータをアクセス可能にすることを意味します。また同じく自分自身がどう表現させるかについて制御したり、選択したりできることも含んでいます。検閲から逃れたり、自分自身のことをどれだけでも多く、もちろん少なくでも自由に共有できることも大切です。 現在ソーシャルネットワークサービスを鑑みると、非常に重要なことだと考えています。TwitterやFacebookのような巨大でサイロなシステムは何百万人ものデータや創造物、くらしそのものをそのシステムに飲み込もうとしています。その上、ほとんどの人が気づかない内に、データは使われているのです。もしTwitterが明日無くなったら(可能性はもちろんあります、何しろVineは終了するのですから)、あなたの履歴や他者とのインタラクションはどうなるのでしょうか? 我々が社会全体として、この10年間ほどで集約してきた巨大なデジタルの歴史達をただ諦めることしかできないのでしょうか。この世代の文化そのものがそれを生み出した人たち、そしてそれらを貴重だと思う人たちの手から離れて、インベスターの気まぐれやデータセンターのちょっとした不具合によって、消え去ってしまうかも知れないわけです。



This is part of what motivates me personally to work on decentralising the social web. In the SocialWG we are creating open standards for:

その事実こそが、私自身がソーシャルWebを分散させようとするモチベーションとなっています。Socialワーキンググループでは以下のような標準を作成中です。

• representing social content
• creating, updating and deleting content
• federating updates between different servers through decentralised subscription and notification mechanisms

• ソーシャルコンテンツの代理
• コンテンツの作成、更新、削除
• 分散化させたサブスクリプションと通知のメカニズムを通じて、異なるサーバ間における情報更新を連合させること



The idea is that people implementing our standards using completely different technology stacks, and without any discussion between themselves, can build systems which talk to each other for some of these kinds of interactions.

標準が異なる技術で実装されようと、お互いの議論もなく、以下の様なインタラクションを行うシステムを構築できること、というのが全体のアイデアです。

Now we know not everybody can have their own website to replace social media. We also know that the big social networking sites are not going to make it easy for people who want to move their data around, or for developers to create decentralised competitors. There have been people working in this space for a looong time, and it's been an uphill struggle the whole way.

すべての人がソーシャルメディアの代わりとなるウェブサイトを持つことはできません。また、巨大なソーシャルネットワークサイト達がユーザのデータの持ち出しを簡単にしたり、開発者が分散化した競合を開発したりすることを簡単にさせてくれることもないでしょう。これまでにもこの領域でとてもながい間働いてきている人もいますが、その間は長い闘いの歴史しかありません。

Our specs are building blocks for different pieces of the social puzzle. It looks like we have a lot, but they're small and modular to help developers pick and choose the parts they need. Rather than having to implement a whole "social network", you can decide to integrate say decentralised comments into a site you're working on, without worrying about subscription or content creation or even account signup and data storage.

我々が作成している仕様は、このソーシャルなパズルを構成する様々なピースです。多くのことを成さなければならないようにも見えますが、それぞれは小さなモジュールとなっているので、開発者たちが必要なパーツを選べるようになっています。『ソーシャル・ネットワーク』そのものを実装するのではなく、例えば分散化したコメントを、登録やコンテンツ作成、アカウントの作成やデータストレージのことを気にしないで、サイトに統合したりできるような形を目指しています。

We're not aiming for adoption by major social networking players (none are involved in the group) but by individual developers and smaller business for whom collecting social data is not their business model, but rather can be an enhancement for their customers of some other product or service.

我々は著名なソーシャルネットワークサイト達(グループ内にはどのサイトも関わっていません)に導入してもらうことを目的とはしていません。その代わりに各個人の開発者や、ソーシャルデータを集積をビジネスモデルとしていないものの、それらのデータを使って彼らのカスタマーに対するエンハンスメントとして利用するような、小さなビジネスに導入されることを期待しています。

Our specifications are JSON based, and use JSON-LD for extensibility. If you're not familiar with Linked Data, this basically just means using a URL as a globally unique identifier for everything, including relationships between things (which would for example normally just be plain text keys in a JSON object). Sharing URLs this way helps us know when we're talking about the same thing as someone else on the Web, so that we can integrate data across diverse sources, without having to know anything about the other data sources beforehand.

我々の仕様はJSONを基幹とし、拡張性を保つためJSON-LDを利用しています。リンクト・データとは、URLをすべてのデータ、例えば、何かと何かの関連性(JSONオブジェクト内のプレーンテキストのキー名だったりすることが多いでしょう)に対するグローバルな一意の識別子として利用することを指します。URLをこのように扱うことで、あるものが別の人が示したものが同じものであると認識するのに役立ちます。こうすることで様々なソース間でお互いのことを知らずとも、データの統合を行うことができるわけです。



(This is vastly oversimplifying things, see https://json-ld.org to learn more)

(この例はデフォルメしているので、詳しくはhttps://json-ld.orgを参照)

We still have a way to go, and we'd love your feedback as developers. This was a pretty high level overview, and if you have any specific technical questions about the specs up here, I'm happy to answer them.

他にもやり方はあることでしょう。皆様のフィードバックを楽しみにしています。今回共有したのは、非常にハイレベルな概要ですので、もし仕様に関する技術的な疑問などあればいつでも質問してください。

Finally, the WG is finishing at the end of this year, but we're keeping the momentum going with a Community Group which anyone is welcome to join, whether you're a W3C member or not.

最後に、このワーキンググループは今年で終了となりますが、この流れ全体はW3Cのメンバーであってなくても、誰でも参加できるコミュニティグループとして、継続していきますので、興味ある方はぜひ。

Contact

• http://w3c.social (currently redirects to Social Web Protocols, more useful stuff coming soon..)
• WG Wiki: http://w3.org/wiki/Socialwg/
• Mailing list: public-socialweb@w3.org
• Twitter (sorry): @SocialWebWG
• IRC: #social on irc.w3.org

Me

• Amy Guy, W3C & University of Edinburgh
• https://rhiaro.co.uk/
• amy@rhiaro.co.uk
• rhiaro on IRC, and everywhere else.

🏷 decentralisation social web socialwg Tokyo, Japan w3c

Wed 2nd of November 2016 at 7:28pm (+09:00)

Post created with https://rhiaro.co.uk/sloph

Tuesday the 25th of October 2016 at 10:10pm (+09:00)

🔁 https://pandelisperakakis.wordpress.com/2015/09/09/how-to-negotiate-with-publishers-an-example-of-immediate-self-archiving-despite-publishers-embargo-policy/

Amy shared https://pandelisperakakis.wordpress.com/2015/09/09/how-to-negotiate-with-publishers-an-example-of-immediate-self-archiving-despite-publishers-embargo-policy/

the problem of restricted access can easily be solved using existing infrastructures and with a small additional effort on behalf of the authors or their librarians - Pandelis

If you are Web savvy, it is a 'small effort' to self-archive your work in a space you control. But not everyone can manage that. And then, feedback, reviews and collaboration also in a space you control is no 'small effort'. Linking to and from specific parts of other research is not trivial when reports and results are missing fine-grained open identifiers. Maintaining your reputation and tracking the effect of your work (so that other researchers and institutions take you seriously) is no 'small effort'. Searchability and guaranteeing long-term persistence is no 'small effort'. There's still a way to go on both the infrastructure and cultural fronts here.

The (Social) Web has most of the pieces. They just need putting together.

That's what we're working towards with #LinkedResearch.

🏷 https://linkedresearch.org/ academia csarven decentralisation linked research Open Access phd publishing social web

Decentralised Social Web Demos at TPAC2016

The demos at today's decentralised social web breakout session went suspiciously well. Some things weren't pretty, but everything basically worked, and none of us had done any special coordinating before hand. We just showed the stuff we worked on, and it fit together fairly coherantly.

Aaron demoed posting a reply with Micropub and behind-the-scenes Webmention sending.

I showed my site feeds and individual posts as ActivityStreams 2.0, plus a screenshot of Chris's emacs-based reader displaying it:



Chris...

Just live demo'ed ActivityPub client-to-server stuff and server-to-server stuff at TPAC and it worked. Yay for live demos not blowing up! - @dustyweb on twitter

demonstrated Pubstrate posting via ActivityPub to his local site, and peer to peer to another. - @t on twitter

Sarven showed LDN, Solid, Web Annotations in dokieli, notifications sent to me displayed in OnScreen, and the LDN spec self-dogfooding with its own annotations on the side.

We had some good questions/discussion about abuse prevention, and uptake.

Hopefully this energy can be sustained through the next two days of WG meetings!

🏷 activitypub ldn micropub social web socialwg tpac2016 w3c webmention

Wed 21st of September 2016 at 1:12pm (+01:00)

Monday the 19th of September 2016 at 4:06pm (+01:00)

🔁 https://twitter.com/lescarr/status/777875047914561536

Amy shared https://twitter.com/lescarr/status/777875047914561536

Post-platform sociality? @w3c working group on Social Web Protocols for decentralised social systems - @lescarr

🏷 social web socialwg sociam tpac2016

Monday the 12th of September 2016 at 12:49pm (-04:00)

🔁 https://twitter.com/csarven/status/775368043094573060

Amy shared https://twitter.com/csarven/status/775368043094573060

This is super important and exciting development for decentralising and owning your notes, comments and annotations!

You can use dokieli to publish your posts and articles, which provides a UI to let people annotate and reply. For people with their own personal storage, they can choose to store their notes themselves. But this isn't many people, so you can also provide an Annotation Service and host your respondents notes for them instead (lowering the barrier to annotating, without locking them in to your platform permanently).

"⚙ #UI to 💾 #WebAnnotations @ annotationService & #LDP #Solid personal storage https://github.com/linkeddata/dokieli … 🌟 #LinkedData"



- @csarven

🏷 annotation csarven dokieli ldn linked research social web web annotation

6th Social WG F2F

☑ Attending!

Event website

RSVP

6th Social WG F2F Amy RSVP'd to https://www.w3.org/wiki/Socialwg/2016-06-06

Wed 18 May 2016 4:41pm (-07:00)

🏷 attendee decentralised social web decentralised web event phd rsvp social web working group social web socialwg socl2016 speaker w3c

🏷 attendee decentralised social web decentralised web event phd rsvp social web working group social web socialwg socl2016 speaker w3c

5th Social WG F2F Summary

This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!

See also day 1 minutes and day 2 minutes.

We met in Boston on 16 and 17 March. What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome.

ActivityStreams2

AS2 is inching closer to CR. Evan has made a validator at as2.rocks and done a lot of work on conformance criteria which we went through as a group and updated a little; mostly changing SHOULDs to MUSTs.

Discussed and not necessarily resolved a few new open issues, including: considering dropping the Relationship object and reviving it as an extension if necessary; a proposal for a new property to say when something was deleted; weakening the SHOULD requirement on name; clarifying scope and context.

Stay tuned for a new working draft sometime soon.

SocialPub

The most exciting thing I thought was agreeing on the potential for convergence between the create, update and delete parts of Activitypub and Micropub.

Micropub started life as a super small and simple way for clients and servers to agree how to create content on a website by POSTing form encoded parameters to an endpoint. As a result of this simplicity, there are dozens of client and server implementations, allowing people to use each others posting clients to add posts to their site, from simple text-only posts to photos, events, RSVPs, likes, bookmarks, reposts. When Micropub needed update and delete, it grew beyond what form-encoded parameters could sensibly handle, and added in a JSON syntax which I think to date only the editor has implemented.

Activitypub uses a JSON syntax (ActivityStreams2) from the outset for create, update and delete, and when you compare this with the Micropub JSON they look remarkably similar.

My posting endpoint implements create the AP way, and endpoint discovery the MP way. It also catches Micropub form-encoded requests and translates them to AS2 JSON before proceeding, so I can still use simple Micropub clients. My posting clients burrow (checkins), obtainium (purchases), replicator (food) and seeulator (events, RSVPs, travel plans) all post AS2 JSON... after discovering the endpoint via rel=micropub. Next on my list, and well overdue at this point, is adding update and delete to both server and clients.

So I proposed we write a document that unifies the common parts of AP and MP, iron out the smaller differences, and hope this coalesces into a small create/update/delete spec which both AP and MP can reference rather than duplicate. Because modularity is good, and common modules are better! I dubbed this temporarily (or is it?) SocialPub.

So what's left in Micropub? I hear you cry. The super simple form-encoded create which is what made Micropub do so well in the first place is really what makes Micropub micro, so I'd like to see this be the bulk of the Micropub spec, with just a pointer to SocialPub for people who want to level up to JSON.

There are still more than a few issues to be dealt with, though we handled a few during the meeting (such as media uploads). I'll be writing SocialPub up into the Social Web Protocols doc next week, stay tuned.

Demos

Jessica and Chris demo'd Media Goblin federating with pump.io! Which is cool. Which brings them a huge step closer to implementing things with AS2/AP and federating that way. They discussed how one of their main impediments had been database schema migration.

Aaron demo'd his Micropub editing UI, which allows partial edits on the post, only for data he is most likely to want to edit (tags, syndication URLs and date).

Aaron also demonstrated a new event posting interface in Quill which uses Micropub, and showed how RSVPs from Woodwind (a feed reader) work via Webmention. Tantek and Ben also demo'd RSVPs from their sites. And Ben demo'd how he can post reactjis as replies, exemplified with the poop emoticon, and there is no question that the future of the social web is in safe hands.

Frank demonstrated federation between OwnCloud servers, which uses WebDAV and CalDAV, and talked through their access control.

Admin/Process

We also had a couple of admin/process related discussions. The first included agreeing to meet at TPAC in Lisbon in September as it already looks like there'll be critical mass to make it worthwhile.

Sandro has made a list of issue labels for github which we painstakeingly went through to make sure everyone understands them and editors are willing to use them on specs. This should help people to figure out at a glance what the current state of a spec is from the issues, as well as help passers-by to jump in if they want to get involved.

🏷 activitypub activitystreams as2 meeting micropub phd social web protocols social web socialpub socialwg standards w3c webmention

Tue 29th of March 2016 at 10:43am (+01:00)

In reply to: https://www.w3.org/wiki/Socialwg/2016-03-16

Amy planned a trip from to

🏷 attendee crosscloud event hacking mit phd social web socialwg

Mon 7th of March 2016 at 11:35am (-05:00)

In reply to: https://aaronparecki.com/2016/03/14/1/indiewebcamp

Amy planned a trip from to

🏷 attendee event hackathon hacking indieweb indiewebcamp organiser phd rsvp slogd social web

Mon 7th of March 2016 at 11:26am (-05:00)

In reply to: http://crosscloud.org

Amy planned a trip from to

🏷 attendee crosscloud event meeting mit phd qcri rsvp social web solid travel

Sun 21st of February 2016 at 4:00pm (-05:00)

Social Web WG 4th face-to-face summary

This post is my own opinion, and does not necessarily represent the opinion of the Social Web WG!

See also day 1 minutes and day 2 minutes.

What follows is more detail on my perspective of the main conversations we had over the two days. Clarifications and corrections welcome.

tl;dr

• Most AS2 issues are closed! CR-blocking issues are now due by 15th December.
• We took a bunch of things to Editor's Draft and are pushing for FPWDs as soon as is viable.
• Some of the drafts overlap but there's a general feeling that since there are keen editors we should work on everything and iron out issues and redundancies as we go, rather than holding out and waiting for clarity.
• Go check out the specs and build bits of them and give the editors feedback!

ActivityStreams 2

We steamrollared through AS2 issues, which included core simplifications, vocabulary changes and reductions and editorial clarifications. James made most edits during the meeting, so there's a much updated working draft available now. You should read it and post any issues you see to be CR-blocking by the 15th of December.

JSON-LD related stuff has been moved to its own section; since it is optional, having references sprinkled throughout was confusing for people who don't necessarily want to deal with it. Chris pointed out that even for extensions, if you know the extension you want to handle you can still do that in plain JSON.

Still some consternation about which alternative syntax examples should be in the spec. Since they're non-normative/editorial anyway they're not a CR-blocker so left alone for the time being.

We don't need a verison number in the URL because any future widely-deployed extensions that want to make it into the core will likely be incorporated as part of a full new version (ie. AS3). At some point we should start a registry for extensions; James is keeping track himself on github, we could move this to a wiki page and ultimately a CG when the WG wraps up.

Lots of discussion about testing frameworks and how to meaningfully test production and consumption of syntax and vocabulary. I refer you to the minutes, as this is beyond my ability to summarise well enough, but it seemed like the people working on this gained some clarity and a plan to move forwards.

Social API

Editor's Draft all the things

There's some contention around what it means to accept a spec as an Editor's Draft in the WG. Our general consensus was that it means a spec isn't necessarily going to be rec-track, or even the direction the group is going to take, but it's in-scope and worth some portion of our attention, even if that is just to inform other things. Most specs we've picked up are work that the editors were doing anyway, and this just means the WG should explicitly not ignore them. It's expected that the specs will change significantly going forward, in response to input from the WG.

As such, it's okay that some of our now-ED specs currently cover overlapping territory. We hope that WG attention will serve to refine, cut, expand, merge, and otherwise sort this out. We may end up multiple small specs derived from our current set of EDs which cover pieces of the social puzzle, or several specs will demonstrate multiple viable ways of doing the same thing. My preference is for the former, but the latter is better than nothing. (I tentatively extrapolate the latter into either one gets wide adoption and the others quietly fade out, or they all get equal adoption and people build bridges between them, either way not a total loss).

Social Web Protocols

I finally convinced people to stop calling this "Amy's SocialAPI Document" and renamed everything to Social Web Protocols. This document describes the individual componants we are trying to standardise (based on user stories), covering both the API and Federation. Given the potential for the WG to produce multiple small specs, work on this is to continue to describe and serve as a guide to each building block. This should highlight both points of convergence between separate specs, and gaps that no existing specs are filling adequately.

Issues filed should be to that end. Point out obvious points of commonality between specs that I haven't noted, or where it would be worth replacing the vague overview with more spec-like details.

I aim to take this to FPWD next week (which does not imply WG consensus on the contents yet) with the expectation that this is currently an overview document: a guide to the different areas being standardised by the WG. If we end up with a bunch of small (or overlapping) specs, this could end up as a Note, detailing how they relate to each other as a guide to implementors. If we end up with one spec that covers everything, either this becomes it following input from the other drafts, or this has done its job at converging things and is dropped completely. The rationale behind going to FPWD with this document is to better advertise and explain the different angles of work the WG is doing to other WGs and the public, and to seek wider feedback thereon. The issues become a place to discuss features based on functionality, where they are not specific to one of the other individual specs.

ActivityPump and Micropub

Both now EDs. Micropub covers a subsection of functionality of ActivityPump, but is uncoupled from any other pieces of functionality, whereas ActivityPump intertwines lots of things. There are distinct similarities - both POST JSON to a specific endpoint to create, update and delete content. The editors are keen to cooperate so there's value in working on them both in sync.

jf2

jf2 is a social syntax to complement (not compete with!) AS2, where jf2 is content-centric and AS2 is activity-centric. The editors of both agreed that it would be beneficial to work on these in conjunction. I've written more about the relationship between them here.

Post type discovery

PTD is an algorithm to help consumers who find themselves with implicitly typed objects to derive explicit AS2 types, if that's what they prefer to work with. My concern is that it's biased towards the microformats2 vocabulary and currently useful for a niche - but a very small niche. However, James pointed out that types are actually optional in AS2 in general, so it could be expanded to help go from untyped AS2 objects to typed ones as well.

My other concern is that this space is such a moving target, and having a fixed algorithm to derive post types based on properties is going to get dated really fast. A constantly shifting algorithm doesn't fit into W3C workflow, and of course brings its own problems (who has implemented which version as it changes over time). I don't have an answer to this.

Federation: Realisations and moving forward

Evan forced us to slow down and really think about what we meant by federation. I don't know if anyone else did, but I had a bit of a lightbulb during this discussion. Bogged down in the particular bits of federation that are within reach to me (basically, notifications), I forgot there are a great many other things one might want to federate, like search, following topics, user discovery, recommendations... The WG is not required to tackle all of these, as a 'federation protocol' is the icing on our charter cake, but we absolutely don't want to de-prioritise federation completely as it's important and actually ties in well with a lot of the work we're already doing. But taking a step back to reassess - and clarify to the outside world - what we're actually doing is important, and there's some effort going into that now.

Webmention

Webmention has been an ED for a short while, and there were some issues to work through. Some really interesting points have been raised around technical details, security concerns and functionality enhancements, and lots of different ways to refine this spec are emerging. We talked through open issues, and group resolutions were made for most of them.

The one I'm most interested in is addition of the property parameter for better disambiguation of the assertion being made by a webmention. It surfaces a need of people outside of the current core webmention implementors to send and verify claims more precisely, whilst adding minimal additional overhead for those who don't need it. Since bringing this spec to the WG is an effort to gain wider adoption and investigate broader use cases than what we have at present, taking these kinds of expansions seriously is good. The benefits were positively acknowledge overall, and I was hoping we'd see this added to the current version, even if marked 'at risk' pending future implementations. But the decision was taken to leave it out, in the same vein as AS2 currently relegating all addition suggestions to extensions. On the plus side, the webmention spec will link to all proposed extensions which are written up as specs, and if any extensions see enough adoption over the course of the work they can be integrated into the core.

Cooperation

Bridging between worlds has been an ongoing theme in this WG.

Chris has done some great work on Activipy, a Python library for handling AS2, and overnight between meeting days he added support for jf2 as well by simply passing in an alternative JSON-LD context. This means you can pass in AS2 and serialize out again as jf2, and vice versa! More or less, at least... this might even be improved by adding PTD in between for where mappings aren't already obvious.

In general, tensions between specs that could be overlapping have changed to editors supporting each other to drive all of the work forward, and, I'm hoping, to optimise where redundancies exist. We all have the same goals, after all. We've still got a long way to go, but we ended on the feeling that we can probably get there.

And we played almost no SocialWG bingo, so it must have been a good meeting.

🏷 activitypump activitystreams as2 federation indieweb jf2 meeting mf2 microformats micropub phd social protocols social web socialapi socialwg standards w3c webmention

Mon 7th of December 2015 at 11:59pm (+00:00)

Things and happenings: modelling social for the web

The online social world is simultaneously and varyingly a mirror, augmentation, and reduction of our offline social lives. Human behaviours are complex and nuanced and context-dependant, inconsistent, sprinkled across many different media, subject to multiple interpretations.. and all kinds of other words that mean it's difficult to wrangle this space into a coherant or complete data model. But, we (computer scientists, software developers) do it anyway.

For some reason, nobody has come up with a solution that pleases everybody yet.

It seems probable, given the diversity of systems, requirements, desires and general worldviews, nobody ever will. So here I come, blazing in with neither history nor experience, to try to write about how I see things. There's a lot of interesting past work in this space, and a full literature(/mailing list/blog post) review is worth doing. But for now, in the interests of time and sanity, I'm sticking to the current state of things as I understand them. In this post, I look at only two different (but overlapping) models. I also want to emphasise that there can't possibly be a single right way of looking at this space. Such models aren't in conflict (as some may think) but simply different ways of looking at the same thing. Where proponants of one may see shortcomings in the other, the opposite is equally true. People's different experiences and needs have led them a way of looking at things that they find perfectly intuitive. Often, this means alternative perspectives are seen as unintuitive and perhaps even in competition. Of course, there's a fine line between accounting for different perspectives, and losting interoperability entirely.

So, let's take stuff. We start with the idea that there is stuff on the social web that we want to describe. One subset of stuff is people. I'm not thinking about modelling people and relationships here.

Other subsets of stuff, which I want to focus on right now, are things and happenings. I'm deliberately trying to pick silly terminology to keep this abstract. You might also think of things as content, items or objects, and happenings as events, interactions or activities.

The two social data models I've spent the most time thinking about recently are ActivityStreams 2.0 and microformats2 (AS2 and mf2 henceforth) and the relationship between them. To various degrees, I've written about them before.

AS2

ActivityStreams was designed as a model for logging happenings (as opposed to a command language, which in some systems it has been used for). AS2's strength is happenings. A happening is modelled as an Activity, which may have a relation to a thing, aka an Object. (Technically an Activity is a type of Object, as is everything else, Actor, Collection, etc, but what I'm referring to here are generic Objects that don't belong to one of these other special classes). There are more specific types of Activity in the AS1 vocab than there are Objects.

mf2

Microformats was designed for marking up all kinds of web documents, and a subset of mf2 is focusing on social, specifically feeds and blog posts. Most people who work with mf2 find that they can adequately represent anything they need to as a thing. mf2's strength is things. The most common type of thing is an entry (a post), and you're also likely to see feeds and cards (profiles). All things can have relationships with other things. There's no particular language for logging happenings with mf2; the existence of a set of things serves that purpose. And no specific types of thing; rather, types of thing are inferred from the semantics of their properties and relationships with other things.

jf2

Both have JSON representations. This is the default for AS2, but mf2 is embedded in html, which means their JSON representation is generated by a parser. Even though there are a set of parsing rules, output can be complicated and vary depending on the structured of the html being parsed, and I've found myself writing my own 'parsing rules' to extract what I want from parsed mf2. Fortunately Aaron and Ben are working on a vastly simplified JSON representation of mf2, called jf2.

All together now

AS2 is already under the remit of the W3C Social Web WG (edited by James), and at the recent face-to-face, jf2 was (somewhat controversially) accepted as an Editor's Draft for the group as well.

The WG is chartered to produce a 'social syntax'. AS2 works great for those with happenings-centric worldviews, but doesn't always sit right with those who want to focus on things. On that basis, I think the two syntaxes have the potential to complement each other. I don't see why the WG can't produce two syntaxes for these two perspectives, which can be used together in systems which mix and match things and happenings. Not everyone agrees. There are certainly some redundancies and overlaps with both specs in their current state, and thus a lot more work to be done. But the editors are all keen to work together to iron these out, and I'm hopeful that now there's more of a feeling that these specs are complementary rather than competing, working on this will improve both. The strengths of one can plug the weaknesses of the other, and everyone can benefit. We also need to leave room for expansion in the future, as obviously this is anything but a static space.

An addendum for those who are adamantly opposed to one or the other of the models, because the other is obviously right/better: I encourage you to accept that different experiences lead to different conclusions, and if there was an obviously right/better way of doing this we'd have solved it long ago. Bringing together the different experiences of different people in order to benefit everyone is kind of the point of the WG.

These are the two models being considered because their supporters wrote them up as specifications and can demonstrate history and implementation experience. Anyone have a different model of the social world they wish to bring to the table..?

🏷 activitystreams2 as2 phd social web socialwg

Mon 7th of December 2015 at 5:07pm (+00:00)