Re: a common understanding of profiles

On 06/29/2015 12:01 AM, Melvin Carvalho wrote:
> On 28 June 2015 at 23:31, Harry Halpin <hhalpin@w3.org> wrote:
> 
>>
>>
>> On 06/28/2015 10:53 PM, Melvin Carvalho wrote:
>>> On 28 June 2015 at 22:13, Harry Halpin <hhalpin@w3.org> wrote:
>>>
>>>>
>>>>
>>>> On 06/27/2015 09:10 PM, Melvin Carvalho wrote:
>>>>> On 26 June 2015 at 23:22, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 06/26/2015 11:17 PM, Melvin Carvalho wrote:
>>>>>>> On 26 June 2015 at 22:58, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>>>
>>>>>>>> Again, I think http URIs and using #s to separate humans and
>> documents
>>>>>>>> are in general good ideas and support that in RDF-based systems.
>>>>>>>>
>>>>>>>> However, as the WebID+TLS community in the past has been unable or
>>>>>>>> unwilling to update or change their  authentication protocol in
>>>> response
>>>>>>>> to noted and kinda well-known security/privacy issues with
>> WebID+TLS,
>>>> so
>>>>>>>> I'm not sure further discussion is productive on this mailing list.
>>>>>>>>
>>>>>>>> Regardless of security/privacy issues, as TLS client negotiation is
>>>>>>>> being dropped in TLS 1.3 due to the triple handshake attack, it's
>>>> pretty
>>>>>>>> obvious that WebID+TLS should not be used as a general purpose
>>>>>>>> authentication protocol in the future as browser support for even
>> how
>>>> it
>>>>>>>> works today will be phased out over time.
>>>>>>>>
>>>>>>>> Rather, the WebID community I would suggest looking at the TLS Token
>>>>>>>> Binding discussion, or improving WebID+RSA or the FIDO work.
>>>>>>>>
>>>>>>>> I'm happy to write these well-known issues up and send them to the
>> WG.
>>>>>>>> If you doubt these points, you may wish to communicate with the TLS
>>>> WG,
>>>>>>>> the IETF SAAG, or the W3C WebSec WG to get in touch with folks in
>>>>>>>> industry and academia who are working on these problems and may have
>>>>>>>> more time to discuss these issues with you.
>>>>>>>>
>>>>>>>
>>>>>>> Thanks for the offer of writing up the "well known" issues, that
>> would
>>>> be
>>>>>>> welcome.  I know you have strong views here, so, in general, a write
>> up
>>>>>> or
>>>>>>> pointers (as above) would be appreciated.
>>>>>>
>>>>>> These issues are strangely enough well known in the larger security,
>>>>>> privacy, and cryptographic research community, which it seems the
>> WebID
>>>>>> community could use more interaction with. Good luck!
>>>>>>
>>>>>> I'll send a doc out if I have time, but the links are below from Ryan
>>>>>> and Brad.
>>>>>>
>>>>>
>>>>> Harry, please dont say you would be "happy to" do something, unless you
>>>> are
>>>>> prepared to follow through with it.  If you claim there are well known
>>>>> issues with something, then you can be expected to be asked what they
>>>> are.
>>>>> I think it's clear from the conversation above, that you're not up to
>>>> date
>>>>> with the subject material, in this case.  So soon after being asked by
>>>>> TimBL not to quote him out of context, you seem to be doing it again.
>>>>
>>>> I am not quoting TimBL. I just said I support WebID as http URIs with
>>>> the use of #s.
>>>>
>>>
>>> Quote: "by WebID you mean what TimBL means, i.e. identify people using
>> URIs"
>>>
>>> If you had been referring to the timbl's web axioms that anything of note
>>> should be identified using a URIs, then sure.  But that's not what WebID
>>> means.
>>>
>>> WebIDs are HTTP URIs that support turtle.  Hash URIs are recommended.
>> That
>>> is what's in the webid spec that timbl authored.
>>>
>>> I hope this is clear now.
>>
>> Yes, I noted the WebID vs. WebID+TLS distinction in this e-mail, so
>> *why* are you repeating yourself?
>>
> 
>> https://lists.w3.org/Archives/Public/public-socialweb/2015Jun/0060.html
>>
>> Note my comments on clarifiying the security/privacy issues apply to
>> WebID+TLS. When most people say WebID they mean "WebID+TLS", which of
>> course has all security/privacy issues mentioned earlier, and thus the
>> lack of support and implementation from the larger W3C community. IMHO
>> It would *definitely* be useful to decouple even further WebID as "URIs
>> to identify people that return a profile" from "WebID+TLS".
>>
> 
> Quote: "most people say WebID they mean "WebID+TLS""
> 
> No, most people dont.

That's not the impression I tend to get, but I'm happy to see WebID+RSA
try to fix some of the issues in WebID+TLS. There's new issues in
WebID+RSA (i.e.  you really should use different keys for signing and
encryption), but these are solvable.

> 
> We wrote a whole spec to make this clear.

I think you may want go back to drawing board a bit rather than treat
everything out of this CG as something that can't be changed. Changes in
TLS and implementation takeup would point to that direction. That's the
point of a CG, i.e. pre-Rec work.
> 
> This community has gone out of their way to make this distinction clear,
> particularly to you, and you are undermining that work.
> 
> WebID is VERY well defined.

Yes, as I noted in my email above you ignored :)

> 
>>
>>
>> You can also read my previously mentioned email to see a hopeful but
>> realistic take on #s and Turtle being adopted outside the community
>> already using them. Thus, you may want to make #s and Turtle optional
>> for WebID, and focus on interop in terms of JSON-LD (JSON with a good
>> default context) if you want people outside the RDF community to use
>> WebID and thus have the ability to link profiles. Turtle is a great
>> syntax for RDF, but I imagine RDF-aware people can roundtrip quite
>> easily between the two.In terms of #s, you could always auto-append a #
>> to a URI of a non-# using system (i.e the majority of systems out there)
>> for RDF inference purposes.
>>
> 
> No, that's a bad idea, because trailing #'s dont work with qnames.

Qnames, last time I checked, were part of XML and did not concat URIs
properly, although just adding a # would at least solve the inference
issue.

You could always use "#me" automagically added. I see no giant
difference, but if it solves some problem, great!
> 
> 
>>
>> Of course, if the WebID community wishes to not engage with the rest of
>> the non-RDF world, that's fine but that's a loss for you all obviously,
>> since as the Social Web WG shows, we have to bring together very
>> disparate communities to create a standard for interop in terms of
>> decentralization. Otherwise, a 'decentralized' solution just ends up
>> being a small, decentralized silo.
> 
> 
> That's slightly condescending.

Why would interop be considered condescending. Is it not more
condescending to push a solution without knowing about other relevant
communities, Working Groups, and research?

Furthermore, it's true - not just of WebID+TLS but also of Diaspora
(whose uptake is about 200,000) and IndieWeb (whose community is
probably similar sized, if not larger, than the WebID-using RDF community).

You are going to have to get interop with existing solutions, and may
likely have to talk to people who do not use RDF. If you don't want to
do that, you can probably still have lots of fun with the RDF community
but  you should probably not join a Working Group whose goal is
broad-scale interop across non-RDF using communities. So, what do you want?

I am sure WebID and RDF have a lot of value to add to the larger
conversation if they can be approached as technical solutions and
discussed on those merits.

> 
> This very thread was an attempt to do that.  I asked for feedback from
> implementors and what I got was unrelated opinion pieces from you.  You
> said you'd be happy to write it up your concerns, but when challenged to do
> so, backed down.  If you're not going to do that, let's end the
> conversation here.

Hhow client certs work (i.e. sent in clear) and the decisions of TLS 1.3
WG are not opinions, they are well-known facts whose news never seemed
to get here. It's also rather self-evident that flexibility will be
necessary in dealing with non-RDF using communities.

I sent you the emails from Brad and Ryan re certificates in terms of
WebID+TLS being a no-go. I'm sorry if you are offended, but if you have
problems with their analysis or questions you can always email Brad and
Ryan yourself.



> 
> 
>>    cheers,
>>        harry
>>
>>
>>
>>
>>>
>>>
>>>>
>>>>>
>>>>> In future, If you provide pointers to back up your opinions, It will be
>>>>> more productive, and that much easier to take seriously.
>>>>
>>>> Did you not see the poiners below from Brad Hill (Facebook) and Ryan
>>>> Sleevi (Google)?
>>>>
>>>> You just have to scroll down. However here they are:
>>>>
>>>>  https://lists.w3.org/Archives/Public/public-xg-webid/2011May/0126.html
>>>>
>>>>
>>>>
>> https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/0001.html
>>>>
>>>>
>>>>
>> https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/0003.html
>>>>
>>>> It may take me a week or so to write this down, I can't do it overnight
>>>> nor do I have lots of spare time. Again, all of these points were
>>>> brought up privately (last time by Nadim from INRIA at the Social Web
>>>> F2F) and ignored for a long time.
>>>>
>>>> That being said, the WebID+TLS community could use the fact that TLS 1.3
>>>> is dropping support as an opportunity: The idea of using private key
>>>> material to authenticate in a decentralized fashion is a *great idea*
>>>> and everyone agrees (i.e FIDO, WebID+RSA with separate
>>>> signing/encryption keys, etc.) it makes lots of sense.
>>>>
>>>> A redesign that works with privacy and security concerns would be
>>>> welcomed. However, that would require the WebID community leaving its
>>>> comfort zone and engaging with the security and privacy community
>>>> seriously, which could would be very productive for all concerned. I
>>>> hope you all can actually do that.
>>>>
>>>
>>> Regarding the 'well known' issues as you describe.
>>>
>>> Your pointer is from 2011 and concerns in part performance.  Thanks for
>>> sharing but a lot has changed since 2011.
>>>
>>> The other two are from this month (June 2015), and are not directed at
>>> WebID.  So one wonders to see how an issue raised just 4 days ago can be
>> a
>>> 'well known' problem with WebID+TLS.
>>>
>>> From my experience, I have found Ryan Sleevi to be very conservative,
>>> wanting to block ajax connections to localhost and web crypto api running
>>> on http are things I think he had a hand in.
>>>
>>> So, if you want to raise criticisms of WebID or WebID+TLS, either here,
>> or
>>> unprompted in other working groups, it would be helpful if you were
>>> prepared to be asked to write up a summary of your concerns.
>>>
>>>
>>>>
>>>>    cheers,
>>>>       harry
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Brief links below:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/26/2015 10:25 PM, Melvin Carvalho wrote:
>>>>>>>>> FYI: I've moved this discussion to public-webid, I hope I can field
>>>>>> some
>>>>>>>> of
>>>>>>>>> the comments / criticisms.
>>>>>>>>>
>>>>>>>>> On 26 June 2015 at 21:51, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 06/26/2015 09:22 PM, Melvin Carvalho wrote:
>>>>>>>>>>> On 26 June 2015 at 19:25, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 06/26/2015 05:04 PM, Melvin Carvalho wrote:
>>>>>>>>>>>>> On 26 June 2015 at 14:23, Evan Prodromou <evan@e14n.com>
>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2015-06-26 07:37 AM, Melvin Carvalho wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regarding the URI above.  It can become slightly problematic
>>>>>>>>>> attaching
>>>>>>>>>>>>>>> key value pairs to an HTTP document, also doubling as a
>> Person.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm pretty sure I didn't do that in the example I gave.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well I thought you were tying (for example) the key "@type" and
>>>>>> value
>>>>>>>>>>>>> "Person" to the http doc :
>> https://evanprodmorou.example/profile
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, how to get interoperable profiles?
>>>>>>>>>>>>
>>>>>>>>>>>> Note this question was explicitly scoped to the Social Interest
>>>>>> Group,
>>>>>>>>>>>> as obviously profiles are going to vary alot across systems and
>>>> only
>>>>>>>> the
>>>>>>>>>>>> most generic pieces of syntax. So, could we move this discussion
>>>>>>>> there?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks, that's good to know.  However I dont think all members
>> here
>>>>>> are
>>>>>>>>>>> members of the IG (im not for example).  To the extent that a
>>>> common
>>>>>>>>>>> understanding of profiles is a pre requisite for implementing a
>>>>>> social
>>>>>>>>>> api,
>>>>>>>>>>> it would be good to get that understood.
>>>>>>>>>>
>>>>>>>>>> Anyone can join the IG.
>>>>>>>>>>
>>>>>>>>>> Again, the way to solve this is probably to look at Activity
>>>>>> Vocabulary
>>>>>>>>>> carefully first, and then vCard, and then FOAF and see what is
>>>>>> missing,
>>>>>>>>>> then pull requests with proposed modified changes/mapping to
>>>> Activity
>>>>>>>>>> Vocabulary.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Pick a data standard, and a way to find the profiles. Then,
>>>>>>>> everybody
>>>>>>>>>>>>>> implements that.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> +1 good to re-use a well-known standard.  Typically, that would
>> be
>>>>>>>> VCard
>>>>>>>>>>>> (support across most of the ecosystem), which basically merged
>>>> with
>>>>>> a
>>>>>>>>>>>> good deal of PortableContacts in VCard 4.0. It's got an XML
>>>>>>>>>>>> serliazation, it maps to hCard for microformat users, and
>> there's
>>>> a
>>>>>>>> RDF
>>>>>>>>>>>> serialization for RDF users (not sure why FOAF didn't closely
>>>> align
>>>>>>>>>>>> more, but that could fixed).
>>>>>>>>>>>>
>>>>>>>>>>>> For things that aren't part of core vCard, the IG is empowered
>> to
>>>>>>>> create
>>>>>>>>>>>> and maintain vocabularies (published as Interest Group Notes),
>> and
>>>>>> we
>>>>>>>>>>>> imagined there would be lots of activity and iterations and
>>>>>>>> maintenance
>>>>>>>>>>>> of these vocabularies might go beyond the lifetime of the WG.
>> The
>>>>>> W3C
>>>>>>>> is
>>>>>>>>>>>> happy also co-ordinate as needed with schema.org and IETF on
>>>> these
>>>>>>>>>> issues.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -1 to vcard, I dont think everyone can be expected to implement
>>>> that,
>>>>>>>>>> does
>>>>>>>>>>> anyone here do that so far?
>>>>>>>>>>>
>>>>>>>>>>> In general, I think it's unrealistic to propose "one profile
>>>> standard
>>>>>>>> to
>>>>>>>>>>> rule them all", unless there's a very strong reason to do so --
>> but
>>>>>> if
>>>>>>>>>> the
>>>>>>>>>>> WG wants to go in that direction I would say a stand out
>> candidate
>>>> is
>>>>>>>>>> WebID
>>>>>>>>>>> because
>>>>>>>>>>>
>>>>>>>>>>> - It's already a documented spec
>>>>>>>>>>> - It is already based on standards, and is 5 star linked data
>>>>>>>>>>> - It is already implemented by SoLiD
>>>>>>>>>>> - It is already implemented by facebook
>>>>>>>>>>> - It already has about 1 billion profiles, out there
>>>>>>>>>>> - It provides a discovery mechanism for feeds, followers, friends
>>>>>> etc.
>>>>>>>>>>>
>>>>>>>>>>> Once again, I dont advocate this as being the single choice, I
>>>> would
>>>>>>>>>> rather
>>>>>>>>>>> look for common ground for interop.
>>>>>>>>>>
>>>>>>>>>> If by WebID you mean what TimBL means, i.e. identify people using
>>>>>> URIs,
>>>>>>>>>> I am sure almost everyone agrees that using URIs is the way to
>> go. I
>>>>>>>>>> think there's wide agreement there. I believe Facebook and most
>>>> sites
>>>>>>>>>> indeed do that.
>>>>>>>>>>
>>>>>>>>>> If by WebID you mean FOAF, see above re mapping FOAF into vCard 4
>>>> and
>>>>>>>>>> Activity Vocabulary and seeing what the diff is. Most of the known
>>>>>> world
>>>>>>>>>> implements vCard and there are very mature libraries for almost
>> all
>>>>>>>>>> platforms. Convergence between FOAF/ActivityVocabulary/vCard would
>>>> be
>>>>>>>>>> great, but should be done in IG. FOAF is not supported natively by
>>>>>>>>>> Facebook to my knowledge and has very little developer take-up
>>>> outside
>>>>>>>>>> the RDF community, although Matt Rowe had some excellent export
>>>> tools.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> FOAF is not part of webid, but it is used in the examples.  Do you
>>>>>> have a
>>>>>>>>> pointer to the tools you mention?
>>>>>>>>
>>>>>>>> http://www.matthew-rowe.com/?q=foaf-generator
>>>>>>>>
>>>>>>>> Might not work any more due to bit rot.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Authentication mechanisms such as WebID+TLS is *out of scope* for
>>>> this
>>>>>>>>>> WG. Even if it was, the necessary cryptographic and security
>>>> expertise
>>>>>>>>>> is clearly not here as well. WebID+TLS is not implemented by
>>>> Facebook
>>>>>> or
>>>>>>>>>> any other user-facing vendors to my knowledge (Facebook
>> implements,
>>>> as
>>>>>>>>>> is widely known, a variant of OpenID Connect i.e. Facebook Connect
>>>> and
>>>>>>>>>> my guess will likely support FIDO). People at Facebook, such as
>> Brad
>>>>>>>>>> Hill and chair of the W3C WebAppSec WG, have come out quite
>> strongly
>>>>>>>>>> against WebID+TLS.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Pointer to Brad Hill's comments?
>>>>>>>>
>>>>>>>>
>>>> https://lists.w3.org/Archives/Public/public-xg-webid/2011May/0126.html
>>>>>>>>
>>>>>>>> It's been forwarded before without adequate response or change in
>>>>>>>> protocol about four years ago :(
>>>>>>>>
>>>>>>>> See Ryan Sleevi (Google) in WebCrypto on cleartext/privacy issues:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/0001.html
>>>>>>>>
>>>>>>>> More datapoints:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://lists.w3.org/Archives/Public/public-webcrypto-comments/2015Jun/0003.html
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To summarize the well-known arguments about why WebID+TLS is
>>>>>> considered
>>>>>>>>>> harmful and thus unlikely to be standardized: From a privacy
>>>>>> perspective
>>>>>>>>>> client certificates send personal data (i.e the URI in the SAN for
>>>>>> their
>>>>>>>>>> WebID profile) in the cleartext, unlike even usernames and
>> passwords
>>>>>>>>>> over TLS. From a security perspective (see triplehandshake attack)
>>>>>> there
>>>>>>>>>> are so many security bugs in client certificate authentication
>> that
>>>> it
>>>>>>>>>> is being deprecated by the IETF in TLS 1.3.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This comment sounds like flame bait, and is IMHO damaging.  I
>> think,
>>>> in
>>>>>>>>> general your hostility towards WebID + TLS is not shared by all at
>>>> the
>>>>>>>>> W3C.
>>>>>>>>
>>>>>>>> It's not hostility, its requests for corrections so you should
>>>>>>>> fix/change the protocol. WebID+RSA may make more sense (although you
>>>>>>>> should use a different signing and privacy key - and you may need
>>>>>>>> key-wrapping, which has some issues in WebCrypto in terms of attack
>>>>>>>> surfaces) in the long-run if you want a lightweight key
>> authentication
>>>>>>>> mechanism.
>>>>>>>>
>>>>>>>> In terms of authentication protocols, for passwords SRP makes a lot
>> of
>>>>>>>> sense, w/o passowords there is also HOBA at the IETF:
>>>>>>>> https://tools.ietf.org/html/rfc7486
>>>>>>>>
>>>>>>>>>
>>>>>>>>> More than 50% of the population of Estonia use TLS with X.509 to
>>>> vote,
>>>>>> do
>>>>>>>>> banking and identify themselves.  The system is now being rolled
>> out
>>>> to
>>>>>>>>> Finland.
>>>>>>>>>
>>>>>>>>> Does this also fail your personal litmus test?
>>>>>>>>
>>>>>>>> They do not use TLS client certs or negotiation, they use X.509
>> certs
>>>>>>>> transmitted over an already established TLS connection. I've
>> discussed
>>>>>>>> this with them, and they are actively monitoring WebCrypto and FIDO
>> as
>>>>>>>> they plan to upgrade their infrastructure when the newer standards
>> are
>>>>>>>> deployed.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That being said, the general concepts behind something like
>>>> WebID+TLS
>>>>>>>>>> (use of proof of key material for authentication) is of interest,
>>>> and
>>>>>>>>>> should be discussed in the W3C Web Security Interest Group and the
>>>>>>>>>> Security Area (SAAG) at the IETF for further evolution, rather
>> than
>>>> in
>>>>>>>>>> this WG. In detail, a privacy-preserving technique known as
>> channel
>>>>>>>>>> binding (i.e. binding authentication to a TLS channel without
>>>>>> revealing
>>>>>>>>>> personal information) is being worked on actively in the TLS Token
>>>>>>>>>> Binding at the IETF. User-centric authentication with
>>>>>>>>>> proof-of-possession of key material done using the same-origin
>>>> policy
>>>>>> is
>>>>>>>>>> currently being developed by the FIDO Alliance, with the backing
>> of
>>>>>>>>>> Google, Microsoft, Paypal, and others. I suspect authentication
>>>>>> without
>>>>>>>>>> passwords be a solved problem shortly.
>>>>>>>>>>
>>>>>>>>>> So, let's remain on topic and focus on what is chartered for the
>> WG.
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>>    cheers,
>>>>>>>>>>       harry
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>    cheers,
>>>>>>>>>>>>       harry
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It would be wrong to assume that the point of this working
>> group
>>>>>> is
>>>>>>>> to
>>>>>>>>>>>>>> make Melvin's site implemented in FOAF with Turtle talk to
>>>> Aaron's
>>>>>>>>>> site
>>>>>>>>>>>>>> implemented in HTML with microformats.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess Im not quite seeing it how to implement an
>> interoperable
>>>>>>>> social
>>>>>>>>>>>> API
>>>>>>>>>>>>> without interoperable social profiles.  However, Kingley's
>> reply
>>>>>>>> seems
>>>>>>>>>> to
>>>>>>>>>>>>> make sense. I'll fwd them to the public list.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We're here for the important goals of defining a social
>> syntax,
>>>>>> and
>>>>>>>>>>>> social
>>>>>>>>>>>>>> API, and a federation protocol for the seven billion people on
>>>> the
>>>>>>>>>>>> entire
>>>>>>>>>>>>>> planet -- not to build ad hoc bridges for the few dozen people
>>>>>>>>>>>>>> participating in this group.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ultimately, that means some people here are going to have to
>>>>>>>>>> compromise,
>>>>>>>>>>>>>> hold their nose, and implement a data standard that they don't
>>>>>>>> usually
>>>>>>>>>>>> use
>>>>>>>>>>>>>> or like.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Evan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Received on Sunday, 28 June 2015 22:18:15 UTC