OStatus 1.5 - ostatus | Google Groups

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion OStatus 1.5
Received-SPF: neutral (google.com: 208.97.132.74 is neither permitted nor denied by best guess record for domain of matthew.k...@morelightmorelight.com) client-ip=208.97.132.74;
DomainKey-Signature: a=rsa-sha1; c=nofws; d=morelightmorelight.com; h=
	references:in-reply-to:mime-version:content-type:subject:from
	:date:to:message-id; q=dns; s=morelightmorelight.com; b=RxrfRiKs
	94CJnCHpNbw+6i/MnPnR5Du1nLjti0DvLSNzerkzggzRmANgjtOu5eZaVkh/76w6
	dDpILtq747ZU2v04a10QiIKhLICZW2Nbv88NyMflSC+YwcwdgzPuqiq97/nG40in
	VnWlYQ2DFk3eKnO1xjE80/9AoVegE/PLJF8=
References: <55cf7208-6763-491b-81ed-f5572ac89...@em7g2000vbb.googlegroups.com> <1fb4a184-2040-41a1-bf9a-4f9ca1b62...@q15g2000yqk.googlegroups.com> <CAONf+LRbaL7364+exT9TJPfdCH-GeKGDST__JsrWribPvfg...@mail.gmail.com> <a9f97f27-fc0a-4228-a30a-a725ca66c...@u2g2000yqb.googlegroups.com> <CAM=Pv=R3gRXEGydmPKq49SQ-k=k7btSP2tfPwsM879BfeoR...@mail.gmail.com> <21aa0b50-c45a-42db-8b14-6f298589a...@email.android.com> <52509045-efe6-4e51-b9d3-1687e08b7...@j15g2000yqf.googlegroups.com> <f359952c-947e-4362-a8e2-d89a21bf6...@v12g2000vby.googlegroups.com>
User-Agent: K-9 Mail for Android
In-Reply-To: <f359952c-947e-4362-a8e2-d89a21bf6...@v12g2000vby.googlegroups.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----XP2PX82PK88FMBNM5NGEDNX75Q605Y"
Subject: Re: OStatus 1.5
From: Matt Katz <matthew.k...@morelightmorelight.com>
Date: Fri, 08 Jul 2011 12:14:14 -0400
To: ostatus-discuss@googlegroups.com
Message-ID: <85063dc4-d1eb-4408-a828-c5ba4087a...@email.android.com>

------XP2PX82PK88FMBNM5NGEDNX75Q605Y
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Regarding remote site operations, perhaps some tweak of oembed is useful.=
 Let them define their remote ops.
--=20
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Laurent-Walter Goix <laurentwalter.g...@gmail.com> wrote:

From an industry perspective it may be worth thinking at the user
concerns first, and thus at those features that social networks in
general, and federation in particular, are related to privacy etc.
As such I definitely agree at supporting privacy levels to restrict
the visibility of activities and introduce 'private messaging' (incl.
1-to-many). I also would emphasize related features such as deletion
(informing other users I deleted some content/activity, read Atom
Tombstones or similar), and portability of user history as already
mentioned in this thread (such as wordpress does import/export or
google takeout): with federation we should expect users to rapidly
migrate across SNs.

Regarding remote site ui, are you thinking at something similar to
oexchange, enhanced to support additional features besides sharing a
link?

As per some other optimizations, say json/atom, I would see them as
secondary as more related to developers' concerns. In particular i
also believe that Atom between federated servers may still be much
more appropriate than json (which I understand is better towards web
clients): as long as the data model is identical (activity streams) I
don't see major issues with this and it doesn't introduce any novel
functionality.

As a side question, may i ask about your intentions where to develop
this new spec? Do you envision to maintain the same process than for
current version or address it under w3c fsw?

On Jul 7, 7:27 pm, Matthias Pfefferle <pfeffe...@gmail.com> wrote:
> I also prefer Atom/RSS, not only because of the technical aspects and
> the better extensibility, but because of the compatibility to the
> "normal" (not federated/indie) web. Up to now status.net lets you
> follow every site which uses a atom/rss-feed (for example
> wordpress.org, posterous, tumblr, twitter, ....) without forcing them
> to implement anything and it allows plattform owners to implement
> OStatus step by step.
>
> On 7 Jul., 18:52, Matt Katz <matthew.k...@morelightmorelight.com>
> wrote:
>
>
>
>
>
>
>
> > I choose json over any xml every chance I get, but I find the pro xml=
 argument much more compelling here. Ostatus as stack of other protocols =
is a good design, and out wouldn't do us much good to support xml AND jso=
n.
> > --
> > Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> > Danny Ayers <danny.ay...@gmail.com> wrote:
>
> > On 7 July 2011 16:05, Singpolyma <singpol...@singpolyma.net> wrote:
>
> > > On Jul 6, 7:02 pm, Max Ogden <m...@maxogden.com> wrote:
> > >> If you want so called "modern javascript" developers to pay attent=
ion to
> > >> OStatus then JSON is a smarter strategic decision
>
> > > "We should do it because it's cool" is not a very compelling
> > > counterargument to "we should not do it because it breaks
> > > compatibility with huge amounts of the web".
>
> > > I'm not saying you can't use JSON for things, I'm saying Atom shoul=
d
> > > remain the primary encoding.
>
> > I put a lot of time into Atom, I believed (and still believe) it's a
> > lot better than random tag soup RSS.
>
> > Now JSON appears to be a lot easier to deal with, but it does have a
> > hole that Atom didn't have. I'll use the swear-word in moment, after
> > saying that Atom is very Web-friendly because it's linky.
>
> > The swear-word is namespaces - ok, now forget that. But JSON seems
> > poor when it comes to having URLs, it tends to have all the worst
> > characteristic of SOAP, that we all hoped we'd moved beyond.
>
> > I've not thought through how to express this properly, but I reckon t=
o
> > go forwards, we want to cherry-pick the best bits of the technologies
> > out there. If we want to use the Web, URLs must be in there from day
> > one.
>
> > Cherry-picking again, I think the data model of RDF is the closest
> > that fits the Web environment, and ... oh dear, now the O Word - the
> > ontologies and vocabulary management bits of the semantic web are
> > worth taking on board. Cherries.
>
> > But cherries on the pie, that I think is something learnt - make the
> > pie first, but do it intelligently with respect to all the background
> > material. Making new stuff is fun, but long-term it's doomed.
>
> > Cheers,
> > Danny.
>
> > --http://danny.ayers.name


------XP2PX82PK88FMBNM5NGEDNX75Q605Y
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body>Regarding remote site operations, perhaps some t=
weak of oembed is useful.  Let them define their remote ops.<br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br><b=
r><div class=3D"gmail_quote">Laurent-Walter Goix &lt;laurentwalter.goix@g=
mail.com&gt; wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt=
 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: =
1ex;">
<pre style=3D"white-space: pre-wrap; word-wrap:break-word; font-family: s=
ans-serif">From an industry perspective it may be worth thinking at the u=
ser<br />concerns first, and thus at those features that social networks =
in<br />general, and federation in particular, are related to privacy etc=
.<br />As such I definitely agree at supporting privacy levels to restric=
t<br />the visibility of activities and introduce 'private messaging' (in=
cl.<br />1-to-many). I also would emphasize related features such as dele=
tion<br />(informing other users I deleted some content/activity, read At=
om<br />Tombstones or similar), and portability of user history as alread=
y<br />mentioned in this thread (such as wordpress does import/export or<=
br />google takeout): with federation we should expect users to rapidly<b=
r />migrate across SNs.<br /><br />Regarding remote site ui, are you thin=
king at something similar to<br />oexchange, enhanced to support addition=
al features besides sharing a<br />link?<br /><br
/>As per some other optimizations, say json/atom, I would see them as<br =
/>secondary as more related to developers' concerns. In particular i<br /=
>also believe that Atom between federated servers may still be much<br />=
more appropriate than json (which I understand is better towards web<br /=
>clients): as long as the data model is identical (activity streams) I<br=
 />don't see major issues with this and it doesn't introduce any novel<br=
 />functionality.<br /><br />As a side question, may i ask about your int=
entions where to develop<br />this new spec? Do you envision to maintain =
the same process than for<br />current version or address it under w3c fs=
w?<br /><br />On Jul 7, 7:27=C2=A0pm, Matthias Pfefferle &lt;pfeffe...@gm=
ail.com&gt; wrote:<br />&gt; I also prefer Atom/RSS, not only because of =
the technical aspects and<br />&gt; the better extensibility, but because=
 of the compatibility to the<br />&gt; "normal" (not federated/indie) web=
. Up to now <a
href=3D"http://status.net">status.net</a> lets you<br />&gt; follow every=
 site which uses a atom/rss-feed (for example<br />&gt; <a href=3D"http:/=
/wordpress.org">wordpress.org</a>, posterous, tumblr, twitter, ....) with=
out forcing them<br />&gt; to implement anything and it allows plattform =
owners to implement<br />&gt; OStatus step by step.<br />&gt;<br />&gt; O=
n 7 Jul., 18:52, Matt Katz &lt;matthew.k...@morelightmorelight.com&gt;<br=
 />&gt; wrote:<br />&gt;<br />&gt;<br />&gt;<br />&gt;<br />&gt;<br />&gt=
;<br />&gt;<br />&gt; &gt; I choose json over any xml every chance I get,=
 but I find the pro xml argument much more compelling here. Ostatus as st=
ack of other protocols is a good design, and out wouldn't do us much good=
 to support xml AND json.<br />&gt; &gt; --<br />&gt; &gt; Sent from my A=
ndroid phone with K-9 Mail. Please excuse my brevity.<br />&gt;<br />&gt;=
 &gt; Danny Ayers &lt;danny.ay...@gmail.com&gt; wrote:<br />&gt;<br />&gt=
; &gt; On 7 July 2011 16:05, Singpolyma
&lt;singpol...@singpolyma.net&gt; wrote:<br />&gt;<br />&gt; &gt; &gt; On=
 Jul 6, 7:02 pm, Max Ogden &lt;m...@maxogden.com&gt; wrote:<br />&gt; &gt=
; &gt;&gt; If you want so called "modern javascript" developers to pay at=
tention to<br />&gt; &gt; &gt;&gt; OStatus then JSON is a smarter strateg=
ic decision<br />&gt;<br />&gt; &gt; &gt; "We should do it because it's c=
ool" is not a very compelling<br />&gt; &gt; &gt; counterargument to "we =
should not do it because it breaks<br />&gt; &gt; &gt; compatibility with=
 huge amounts of the web".<br />&gt;<br />&gt; &gt; &gt; I'm not saying y=
ou can't use JSON for things, I'm saying Atom should<br />&gt; &gt; &gt; =
remain the primary encoding.<br />&gt;<br />&gt; &gt; I put a lot of time=
 into Atom, I believed (and still believe) it's a<br />&gt; &gt; lot bett=
er than random tag soup RSS.<br />&gt;<br />&gt; &gt; Now JSON appears to=
 be a lot easier to deal with, but it does have a<br />&gt; &gt; hole tha=
t Atom didn't have. I'll use the swear-word in
moment, after<br />&gt; &gt; saying that Atom is very Web-friendly becaus=
e it's linky.<br />&gt;<br />&gt; &gt; The swear-word is namespaces - ok,=
 now forget that. But JSON seems<br />&gt; &gt; poor when it comes to hav=
ing URLs, it tends to have all the worst<br />&gt; &gt; characteristic of=
 SOAP, that we all hoped we'd moved beyond.<br />&gt;<br />&gt; &gt; I've=
 not thought through how to express this properly, but I reckon to<br />&=
gt; &gt; go forwards, we want to cherry-pick the best bits of the technol=
ogies<br />&gt; &gt; out there. If we want to use the Web, URLs must be i=
n there from day<br />&gt; &gt; one.<br />&gt;<br />&gt; &gt; Cherry-pick=
ing again, I think the data model of RDF is the closest<br />&gt; &gt; th=
at fits the Web environment, and ... oh dear, now the O Word - the<br />&=
gt; &gt; ontologies and vocabulary management bits of the semantic web ar=
e<br />&gt; &gt; worth taking on board. Cherries.<br />&gt;<br />&gt; &gt=
; But cherries on the pie, that I think is
something learnt - make the<br />&gt; &gt; pie first, but do it intellige=
ntly with respect to all the background<br />&gt; &gt; material. Making n=
ew stuff is fun, but long-term it's doomed.<br />&gt;<br />&gt; &gt; Chee=
rs,<br />&gt; &gt; Danny.<br />&gt;<br />&gt; &gt; --<a href=3D"http://da=
nny.ayers.name">http://danny.ayers.name</a><br /></pre></blockquote></div=
></body></html>
------XP2PX82PK88FMBNM5NGEDNX75Q605Y--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
