Differentiating OSW

[Olaf Zanger]

Thinking for Somerset Years about federated Social I Wonder about how
OSW can Set itself apart Feature wise. I Start this thread to discuss
this in the wider Open.

Set IS the idea of IT beeing Open and federated.

For seeding the Diskussion I throw in some thoughts:
* since it is a federated approach AND registering is not built in
wouldn't it be wise NOT to develop yet another authentication-identity
(to annoy users) but to consequently built on opened /oath
respectively?
* as can be seen on http://wiki.github.com/onesocialweb/osw-openfire-plugin/accounts-that-have-joined-the-federation
a directory is important. This also is one of the great values of fb.
Fb just changed privacy rules and the one thing that the keep in the
open is name, first name and picture - the universal directory.
* grouping: a issue that is limiting use of fb for group private
messaging and sharing is the bad UI for sharing to a group/list/
community. That certainly can be done simpler AND specifically more
visual and with more ensuring fvisual eedback before "sense".

What are your points? Dear OSW nerd?

As you can see on the bad writing, it was iPad day in Europe.

[kost]

One thing that i think is important, feature wise, is complete data
portability:

I want to register on one server, then move to another, then to
another, then back to the first.. and so on, and so on. All that while
I am retaining all my data, followers, profile etc.
Another important aspect of it, is I think i should be able to "back
up" all of my data, and, say, if the server I am on goes down, I
should be able to upload all the data to another server, and that's
it.

What do you think?

On May 29, 4:21 am, Olaf Zanger <olaf.zan...@gmail.com> wrote:
> Thinking for Somerset Years about federated Social I Wonder about how
> OSW can Set itself apart Feature wise. I Start this thread to discuss
> this in the wider Open.
>
> Set IS the idea of IT beeing Open and federated.
>
> For seeding the Diskussion I throw in some thoughts:
> * since it is a federated approach AND registering is not built in
> wouldn't it be wise NOT to develop yet another authentication-identity
> (to annoy users) but to consequently built on opened /oath
> respectively?

> * as can be seen on  http://wiki.github.com/onesocialweb/osw-openfire-plugin/accounts-that...

[Laurent Eschenauer]

On Sat, May 29, 2010 at 3:21 AM, Olaf Zanger <olaf....@gmail.com> wrote:

Thinking for Somerset Years about federated Social I Wonder about how
OSW can Set itself apart Feature wise. I Start this thread to discuss
this in the wider Open.

Good discussion !

 

* since it is a federated approach AND registering is not built in
wouldn't it be wise NOT to develop yet another authentication-identity
(to annoy users) but to consequently built on opened /oath
respectively?

Actually. Registration is built in. It is part of XMPP, just enable it on the server and you have in band registration (supported in the console with the /register command). We have not yet added this to the web client and android one simply because we do not need it now, and focus on other things. As for OpenID, it could be supported but the user experience is broken on things like mobile, which is a key target for us.

* as can be seen on  http://wiki.github.com/onesocialweb/osw-openfire-plugin/accounts-that-have-joined-the-federation
a directory is important. This also is one of the great values of fb.
Fb just changed privacy rules and the one thing that the keep in the
open is name, first name and picture - the universal directory.

Serach, discovery, and therefore a decentralized directory is definitively on the roadmap (0.9). Ideas on UI and protocols are welcome.

 

* grouping: a issue that is limiting use of fb for group private
messaging and sharing is the bad UI for sharing to a group/list/
community. That certainly can be done simpler AND specifically more
visual and with more ensuring fvisual eedback before "sense".

You are not the first one to tell me that lists are bad UI for privacy. However, I have not yet seen anything better :-) If anyone has some UI flows, wireframes, or other ideas, please share ! One other question is: do we need to change something in the protocol to acomodate these other kind of UIs ?

 

As you can see on the bad writing, it was iPad day in Europe.

lol

[Laurent Eschenauer]

On Sat, May 29, 2010 at 5:23 PM, kost <kkap...@gmail.com> wrote:

One thing that i think is important, feature wise, is complete data
portability:

Definitively on the roadmap as well. This is one of the many reasons we picked Activitystreams and Vcard as data model: open and universal. So, you should be able to authorize (OAuth) another party to suck all your data easily. This will most likely be done over HTTP and not XMPP. We plan to look at this when diving into a REST API later down the road. Backup is similar, you just authorize a backup service or backup client on your machine to access all your data.

[Juanjo Alvarez]

* as can be seen on  http://wiki.github.com/onesocialweb/osw-openfire-plugin/accounts-that-have-joined-the-federation
a directory is important. This also is one of the great values of fb.
Fb just changed privacy rules and the one thing that the keep in the
open is name, first name and picture - the universal directory.

Serach, discovery, and therefore a decentralized directory is definitively on the roadmap (0.9). Ideas on UI and protocols are welcome.

Have you considered using webfinger? http://code.google.com/p/webfinger/

One of the good things that Facebook have is nice discovery of your contacts; since the username is the email it's easy for them to tell you what of your contacts are already on Facebook just searching on their databases. OSW being distributed  cannot have it so easily (pure P2P discovery usually is excruciatingly slow, like Gnutella showed in the past) but webfinger could be a solution. The client would do a webfinger request for every one of the contacts in your (gmail or whatever) contact list, and would get is OSW username (juanjux at gmail.com => juanjux at websocial.me for example.)

Of course this would require the mail providers (Google, Microsoft, Yahoo, etc) to support it, but Gmail for example is already there (tought I'm not sure how you can easily edit your webfinger information).

[kost]

Sounds good. I am interested to know how you will handle name spaces.
For example, say I am us...@provider1.com and I want to go to
provider2. Will my name still be us...@provider1.com or
us...@provider2.com?

If it changes to the new one, that means all the people i just gave my
"name" to, becomes invalid. Like, for example I post on, say, some
forum: "you can contact me at us...@provider1.com", if i change the
provider, that post becomes unusable. If on the other hand i keep the
old adress, how would that be handled if the the old server goes down,
and it's dns with it? Will my account not work even tough i moved to a
different provider?

Thanks a lot for sharing with us the insights of this project.

On May 29, 6:39 pm, Laurent Eschenauer <laurent.eschena...@gmail.com>
wrote:

[Olaf Zanger]

since your data is bound to your jid there should the option to "bind"
jid's (a old one, the newer, the newest) together in the data viewer.
this way one could keep the same "human" bound to messages. The owner
(the human behind) of the respective jid-history in his profile entry
could either keep track of the old jid's he had or if wanted "break"
history. And therefor be somebody else in the later stage.

This thoughts i have because a jid has the hoster through the domain.
So if you choose a new hoster, one gets a new jid.

The same concept would be true to other type of id's like Mobile Phone
numbers, appartment addresses, ...

Correlation can be kept if in the profile the history of old
identities is available. Obviousely I would be free to keep the
history of my friends jids even if they choose to break their jid
history for the public. So the "contact" entry of a friend I have in
my data set would be more concise than his public profile. that btw.
is already true today with any outlook data that is more concise than
the white pages entries of my friends.

[Olaf Zanger]

I think down the following road:

discovery happens through the following process:
* type in Firstname, Lastname (for girls pre-marriage name important)
* depending on the amount of available "Max Mustermanns" sometimes you
have to add some location filtering
* have a small amount of same named people.
* Look at their Picture and select THE RIGHT ONE
* Now ask for frienship which actually is "whitelisting"
* ONLY AFTER whitelisting have the opportunity to communicate or share
to them.
A different process happens if you have not a specific person in mind
but rather browse based on other criteria (same interests, friend of a
friend, good looking, ...)

The upper process might or might not work with webfinger. Performance
surely is a issue in a future of 10 billion people and 100 billion
devices.

Why not separate the part of discovery at the point where a friend-
request happens (before the whitelisting)

This upper works great in facebook.

On 29 Mai, 17:51, Juanjo Alvarez <jua...@juanjoalvarez.net> wrote:
> > * as can be seen on

> >>http://wiki.github.com/onesocialweb/osw-openfire-plugin/accounts-that...

[B. Kip]

Two thoughts:

Directory/Search- For privacy- each user should be able to control both IF they are listed in the directory and WHAT info they allow to be shown.  Also some control over WHO can find them- similar to FB 'only friends of friends' or 'anyone'.

Friendship/Whitelisting- I think that a combination of the two-way relationship model of FB and the asynchronous 'following' model of Twitter would be best.  This way you could follow the public status updates of anyone you chose (who made public status updates) and still have private interactions as well.

[B. Kip]

Hi, new member here.  I'm Brad Kipfer of the Drumbeat project: We Need a Free and Open Social Network.
https://www.drumbeat.org/project/we-need-free-and-open-social-network

You are discussing differentiating your project, so I should be open and say my support is not for any single product!
But since you are discussing features I have some comments.  Whether these would work for your application in particular (and how soon) I don't know, but they are features I'm interested in seeing available in future network applications.

* grouping: a issue that is limiting use of fb for group private
messaging and sharing is the bad UI for sharing to a group/list/
community. That certainly can be done simpler AND specifically more
visual and with more ensuring fvisual eedback before "sense".

You are not the first one to tell me that lists are bad UI for privacy. However, I have not yet seen anything better :-) If anyone has some UI flows, wireframes, or other ideas, please share ! One other question is: do we need to change something in the protocol to acomodate these other kind of UIs ?

This is something I've thought about since I find that the 'friend' model of many social networks is too limiting.  In reality we have many kinds of relationships and we even have different persona with different groups of people.  So I want to relate to my family members in some ways, my close friends in others, my colleagues in still others, etc etc.  However I still want to interact with all of them and I want to do so from a single profile on a single network (after all I am one person) without disturbing the sometimes delicate structure of my spheres of relationships.

The way I thought of doing this is utilizing context in some way.  Again, in real life the way we relate to others is highly affected by the context, so it is something we are all used to.  Instead of choosing a group of people to direct a new item to once I created it, it would be much more intuitive if I were already in the right context before I started.  Say for example there were a set of links visible to me when logged in.  These would act something like filters.  So if I clicked 'Family' then suddenly the item stream would be filtered to show only ones from people I had tagged as Family.  In addition, other things would reinforce the context- perhaps a background picture I had selected for the Family page, perhaps a theme I had selected, perhaps certain widgets that incorporated other related information- like local news from my hometown.  All of these things would work together to reinforce the context, so when I was in it, I would feel natural about interacting with this specific group of people.  Each group of people I defined would have such a context generated for them which would be customizable by me.  The usual sequence for updating to my family members would then become: click the Family link and see the Family page, then create the item and send it.

There could also be a 'World' context that would focus on public communication, so that if I wanted to dip into the public stream I could see it, and publish to it.  Of course to be useful this would need search and filter tools to help manage the information coming through.  Another useful context would be 'All my Connections', again used both for reading and for publishing.

[Harlan Iverson]

On Sun, May 30, 2010 at 7:47 PM, B. Kip <bkpu...@gmail.com> wrote:

The way I thought of doing this is utilizing context in some way.  Again, in real life the way we relate to others is highly affected by the context, so it is something we are all used to.  Instead of choosing a group of people to direct a new item to once I created it, it would be much more intuitive if I were already in the right context before I started.  Say for example there were a set of links visible to me when logged in.  These would act something like filters.  So if I clicked 'Family' then suddenly the item stream would be filtered to show only ones from people I had tagged as Family.  In addition, other things would reinforce the context- perhaps a background picture I had selected for the Family page, perhaps a theme I had selected, perhaps certain widgets that incorporated other related information- like local news from my hometown.  All of these things would work together to reinforce the context, so when I was in it, I would feel natural about interacting with this specific group of people.  Each group of people I defined would have such a context generated for them which would be customizable by me.  The usual sequence for updating to my family members would then become: click the Family link and see the Family page, then create the item and send it.

There could also be a 'World' context that would focus on public communication, so that if I wanted to dip into the public stream I could see it, and publish to it.  Of course to be useful this would need search and filter tools to help manage the information coming through.  Another useful context would be 'All my Connections', again used both for reading and for publishing.

I like where this thought train is going. From a strictly protocol standpoint I see OSW's vcard over XMPP extension and various other things like PubSub/PEP/Activity Streams, complete with the OSW ACL, covering most of this functionality (are you familiar with their draft standards, on the osw website?). While I've only read the documents and not studied any implementations (which I assume are partial, if at all), it seems like the elements of a context can be determined by what elements of the vcard are available to a group. Assuming the ACL functionality is powerful enough to grant permission to specific groups (roster? osw social relationship?) that should handle it.

As for the UI of such functionality, I can see FB style listing roster/social relationship groups or a more contextual view specific to a certain 'client' / site. For example the site could have a potentially different layout for each group and show it accordingly based on which group the viewer belongs to or the account maintainer chose to display. In general though, this all seems implementation specific and I have a hard time thinking of a general way to do it from a UI perspective without being limited to web clients.

Today I've been toying with the idea of scaling the analog of FB 'applications' across domains, and the UI aspect is what is hanging me up most. In my sketches, the profile (vcard, personal pubsub, pep, etc) can be viewed by an application of this type that may be implemented in 'web' which can then be loaded into anything that can create an html widget. I only have a few hours worth of work, but if there's any interest I can write up my ideas for something like 'osw-applications' extension. I think something along those lines might be a decent framework in which to talk about contextual profiles.

[Mike]

Preface: I am not of level of understanding of onesocialweb or XMPP to intelligently contribute to this conversation...

However, most people that I know that use facebook do so for the applications/games (Farmville and Cafe-world/ville/whatever), so if an alternative to facebook is the goal, is seems that applications would be key.  I would love to hear your ideas, if you wouldn't mind throwing up thoughts on the wiki (is that an ok place?)

Thanks,

Mike

[B. Kip]

To clarify, I was thinking only in terms of UI, not protocol.  I was thinking of groups formed by attributes added by the user, like 'tags' I could add to each of my contacts.  Tags could be whatever I made them: family, high school friend, college friend, fishing buddy...  Multiple tags could be assigned to individual people.  The application would then filter the activity I was seeing by the tag(s) I had selected at the moment- perhaps by an action like selecting a group I had previously defined using a specific set of tags.  In addition to the filtering the application would generate an interface that would contain the other elements of context I mentioned- eg. background picture, theme elements, gadgets etc.  It would also define the set of recipients of anything I published as long as I was using this interface.

The word 'group' could be confusing, since in this case the group would not be people who had chosen to form a group together, it would simply be the set of people I selected by attributes I defined on my own.

I hadn't thought of how this concept could work as you visited various sites on the web.  That brings up interesting issues and possibilities.  One point is that if these groups were user defined using user defined attributes, it might be difficult for a site to interact with them without the user doing a fair bit to customize the interaction themself (which would not necessarily be a bad thing).

[Luca Faggioli]

How is this concept of Tags different from what we already have in OSW, namely List?

Follow Me on Twitter: http://twitter.com/lfaggioli

---

From: "B. Kip" <bkpu...@gmail.com>

Date: Thu, 3 Jun 2010 08:37:49 +0900

To: <onesoc...@googlegroups.com>

Subject: Re: Differentiating OSW

[B. Kip]

I'm not sure.  I don't know how lists work in OSW.  Can you put people in multiple lists?

I've asked onesocialweb for an account but I think they are too busy (on vacation ) to answer right now.  I saw on your twitter you are offering accounts on openliven.  Could you set one up for our project?  I'll email you directly.

Brad

[James Rhodes]

You can.  In fact it seems lists in OSW are just groups for organising contacts and are standard since Pidgin seems to recognize the groups I put people into ;)

Regards, James.

[Luca Faggioli]

Yes, you can indeed put people in multiple lists...

I will create your account in a minute and I'll send you the details by email

Talk to you later
Luca

Follow Me on Twitter: http://twitter.com/lfaggioli

---

From: "B. Kip" <bkpu...@gmail.com>

Sender: onesoc...@googlegroups.com

Date: Tue, 8 Jun 2010 12:21:52 +0900

To: <onesoc...@googlegroups.com>

ReplyTo: onesoc...@googlegroups.com

Subject: Re: Re: Differentiating OSW

[Daniel Appelquist]

Hi Brad -- yes, both of the lead developers are on a much needed
vacation right now but in any case we are not quite ready to open up
account creation on our OneSocialWeb systems - though we will work
towards this over the summer.

Dan

On Jun 8, 4:21 am, "B. Kip" <bkpub...@gmail.com> wrote:
> I've asked onesocialweb for an account but I think they are too busy (on

> vacation [?] ) to answer right now.  I saw on your twitter you are offering

[B. Kip]

Hi Dan,

Understood on both counts!  That wasn't intended as a complaint, I'm sorry if it seemed that way.  I'm really glad for all the work all of you are putting into OneSocialWeb!

Luca got us set up on openliven (thank you very much Luca!) so we'll be trying it out real soon.

Brad

[B. Kip]

Thank you very much Luca!

I was thinking a little more about tags and lists.  Coming at it from an attribute angle instead of a list angle means that you can have automatically generated self-updating lists.  These attributes could be ones you add to people or ones they add themselves.  So if you have an informal group of people that assemble at the local coffee shop you could add 'coffee shop buddy' to their profiles.  On the other hand people who play soccer in a recreational league could add their team name to their profile.  In either case a list could be generated allowing you to communicate with your coffee shop friends or your fellow team members.  With this method it wouldn't need to be limited to people you know.  You could connect with fans of Australian rules football, or real estate agents living in Houston Texas, or single women in their forties who live in Hong Kong and have a french poodle- all based on whatever attributes people decided to make public about themselves.

[Alard Weisscher]

Hi Brad,

Finally back from holidays with some time to reply!

Directory/Search- For privacy- each user should be able to control both IF they are listed in the directory and WHAT info they allow to be shown.  Also some control over WHO can find them- similar to FB 'only friends of friends' or 'anyone'.

Agreed. This is how we envisioned it.
 

Friendship/Whitelisting- I think that a combination of the two-way relationship model of FB and the asynchronous 'following' model of Twitter would be best.  This way you could follow the public status updates of anyone you chose (who made public status updates) and still have private interactions as well.

These are exactly the two cases we are supporting in OSW.

Fully aligned!

Alard

[Alard Weisscher]

Hi again,

I was thinking a little more about tags and lists.  Coming at it from an attribute angle instead of a list angle means that you can have automatically generated self-updating lists.  These attributes could be ones you add to people or ones they add themselves.  So if you have an informal group of people that assemble at the local coffee shop you could add 'coffee shop buddy' to their profiles.  On the other hand people who play soccer in a recreational league could add their team name to their profile.  In either case a list could be generated allowing you to communicate with your coffee shop friends or your fellow team members.  With this method it wouldn't need to be limited to people you know.  You could connect with fans of Australian rules football, or real estate agents living in Houston Texas, or single women in their forties who live in Hong Kong and have a french poodle- all based on whatever attributes people decided to make public about themselves.

We have been thinking quite about tags and lists and indeed picked the list approach the Luca already pointed out. You can organize people by putting them in a list (you could also call this a tag, but we use the wording of twitter and facebook). These lists can be used for privacy settings (already working) or filtering purposes (todo). It is important that these lists are private: you may not want to let people know they are in the lists "dummies". We can consider twitter style list sharing in future. One thing we have to bear in mind is not to make things too complex. Quite a few people are already complaining about the complexity of privacy settings in the big social networks.

For me this is fundamentally different to creating a community around a specific topic/target group. This is conceptually much more like facebook's fan pages or following a twitter tag. Such fan/community pages are a bit less straight forward to discover in a federated environment.

We have some more fundamental nuts to crack so we want to focus first at the basics and then dive into topics like these.

Cheers! Alard
 

[B. Kip]

Thanks for your reply!

This was more conceptual brainstorming than a request for implementation.  It may be more appropriate in a forum like Gnu Social than here, since it wasn't so much product oriented as dreaming about how things might work eventually on a distributed network.

But I will disagree with you that lists of contacts you create and "creating a community around a specific topic/target group" are fundamentally different :-)

I think it's more a matter of degree, and that both the concept of community and many of the tools we will use in the future will apply at both ends of the spectrum- ie: people you know well and people you have never encountered before.

If you didn't see it, check out my first post in this thread, on 'context'.  It addresses this idea but applies more directly to designing an interface for more intuitive use of lists.

Brad