Re: R: Wiki page Re: Proposal to develop best practice document to focus work of W3C FSW Community Group

On 23 May 2013 12:47, Andreas Kuckartz <A.Kuckartz@ping.de> wrote:

> Goix Laurent Walter:
> > Perhaps in order to make the fsw cg more efficient we could
> >
> > 1)      start identifying some "areas of interest" within the whole
> > fsw topic. E.g. privacy (& distribution), search, mobile, scalability
> > etc.
> >
> > 2)      open anyone/any project to contribute to the areas of his
> > interest and describe how it addressed it and what should be improved
> >
> > 3)      by merging and discussing commonly on each topic we'd likely
> > identify concrete opportunities to make current specs/standards
> > evolve, which imo would be a very nice result of the group.
>
> +1
>
> All of this is very welcome on this list as far as I am concerned.
>
> Several significant projects do not yet seem to be represented here.
> Anyone in contact with Kune or friendica ?
>

I think Mike Macgirvin from friendica posted to this list today.
Friendica is one of my favourite projects.


>
> > Over the past years I led the "Social Network Web" work item within
> > the Open Mobile Alliance forum, which substantially is a combination
> > of the opensocial specs (for device-server communication) and ostatus
> > suite (for federation), with the ability to also reuse phone numbers
> > as user identity. The mapping of opensocial & ostatus communication
> > flows was one of the most challenging part in order to achieve a
> > decent end-to-end spec and we learnt through prototyping the various
> > issues and possible improvements of the core specs we rely on.
>
> Do you have any links regarding that work? Did XMPP play (and why) ?
>
> > To cite some examples: pubsubhubbub & salmon may be evaluated to
> > merge, pubsubhubbub may support additional communication channels, etc
> >
> > Having all the most relevant actors of such specs in this group could
> > be useful to share experiences, issues and proposals for solutions to
> > evolve such specs and eventually converge into a reduced subset of
> > specs that gain consensus.
>
> +1
>
> It should be possible to identify and formulate research questions. That
> could become the foundation for research projects.
>
> > I do believe that the current fragmentation of initiatives slows down
> > the deployment of large federations...
>
> +1
>
> This is perhaps the main issue we can help to improve in this group.
>
> Most projects seem to attempt to build their own "federation" islands
> without federating with other projects. It is easier to build a
> centralised Social Media platform than a federated one. And it is easier
> to build a federation using only one software product than one including
> other products. Most difficult seems to be to create a federation
> consisting of nodes using different software products.
>

+1

Just to say, I dont think the fragmentation is intentional.  It's sometime
possible to introduce fragmentation without intending to do so.  For
example in system 1 Alice is allowed at most two phone numbers, and in
system 2 Alice is allowed at most one phone number.  It becomes possible
for alice to transfer her profile from system 2 to system 1, but NOT vice
versa.  I think most founders want to be federated, but it's the small
details that can create barriers at coding level, the bottleneck tends to
be to get patches written and promoted upstream, when you have many other
things on your plate.  I think this is where a best practices document
could be invaluable.


>
> Cheers,
> Andreas
>
>