What we've been working on: Diaspora “Sharing” Model

[Daniel Grippi]

Hello Diaspora,

------- TL;DR
We are implementing a new way to connect to people online.  It is getting rolled out next week. It is somewhere in between a follow and a bi-directional relationship.  When you share an aspect with someone, you start seeing their public posts right away.  If they share back, you have a fully bidirectional relationship.
--------

In a few days, we’ll be upgrading Diaspora’s relationship model to something we call the “share”  model. We believe it’s a more elegant way to connect with other people on the network.  We’ve been working on it over the past month, and we’re happy to announce that it’s ready to go.  Before merging this work into Diaspora’s master branch and deploying this feature onto our on servers, we want to give you a heads up and explain what this new model means to both end-users and developers.

At it’s core, “sharing” is how we’re implementing asynchronous relationships.

Our current bi-directional relationships fall short. They introduce too much friction to exploring all the wonderful public conversations on the Diaspora network (especially for new users).   New users face a lonely, empty site.  We considered implementing the familiar follow model, but we wanted a system that embraced the asynchronous nature of a follow without losing the benefits of aspects.

For users the interaction is only slightly different:

Putting another user into an aspect means sharing with them.  Sharing includes following; you’ll see another user’s public posts in your stream as soon as you put them in an aspect.   They, in turn, can immediately see the face that you want to present to them through your profile private posts.

Once two people are sharing with each other, the relationship between the two is exactly the same as what we currently have:  Connected people able to share privately with each other. This allows for more intimate relationships while addressing the “friction” and “loneliness” that we originally found.

For developers not much has changed:

These changes have allowed us to simplify our data model.   We’re dropping the Requests table and replacing it with two columns in the Contacts table.  Upgrading means pulling and running a migration that will translate the Requests table over to the Contacts table.  That’s it.

For pod-runners:

Since the new model is not backward compatible (although no permanent damage can be done by contacting an out dated pod) on the protocol level, it would be good to upgrade at the same time. We are going to do it at 10 am PDT, Monday May 16th let us know if that's problematic for anyone.

During the time that servers aren’t running the same version, changes in relationships between servers running different versions won’t work, but the upgrade will clear any broken state left in the requests table.

We’ll be happy to answer any questions you might have about this transition.

Daniel & Ilya

P.S. We’ll write a blog post about this in the next couple of days.

[david]

Sounds like good changes! Thx for the update.

> Monday May 16th<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Diaspora+Sha...>let

[Boon Kiat, Han]

the longer we drag the big launch

the more time the facecrook guys will have to hatch features that they entrench their users with

(@#uckerburg didn't invest in Diaspora to egg us on)

i still think that it will require
- various ports, some minimal (communicating only the least api to not break the network)
- various hosting providers, oversight by diaspora community, to destroy the bar of entry of running server

lets rock this vending machine over

---

From: david <david....@gmail.com>
To: diaspora-dev <diaspo...@googlegroups.com>
Sent: Fri, May 13, 2011 10:31:11 AM
Subject: Re: What we've been working on: Diaspora “Sharing” Model

[Jonne Hass]

Okay a few questions:

Will I be able to comment on public posts I receive when I'm following someone?

Will there be a list of people following me? Will it be public? If so it should be possible to turn it off.

What happens to currently broken connections, i. e. when someone has a pending request but the remote pod never received the request?

What happens when the connection can't be established, will the user be notified or just think he is following the remote by never receive anything?

Will there be a flag indicating if its a bi-directional or a follow contact? Will that flag be switched back if one party removes the connection?

Will a contact I'm following be removed from the lists for mentions and conversations so a user isn't trapped on thinking he can and successfully did contact him?

Thanks,
Jonne

[Ritchie Wilson]

Which branch will you be merging? Is that the "follow" branch available through the github repository? It would be good to look at the code

[Daniel Grippi]

On Fri, May 13, 2011 at 5:34 AM, Ritchie Wilson <rawil...@gmail.com> wrote:

Which branch will you be merging? Is that the "follow" branch available through the github repository? It would be good to look at the code

On Fri, May 13, 2011 at 1:00 AM, Jonne Hass <list-...@mrzyx.home.kg> wrote:

Okay a few questions:

Will I be able to comment on public posts I receive when I'm following someone?

Yes.

 

Will there be a list of people following me? Will it be public? If so it should be possible to turn it off.

 

Currently in our branch (follow), only you can see the list of people who are sharing ("following") with you.

What happens to currently broken connections, i. e. when someone has a pending request but the remote pod never received the request?

We can either delete all pending contacts and incoming requests, which would reset the state, or we could unsafely assume these connections have been made, and create uni-directional relationships.  This obviously, is up for debate.  Glad you brought it up.

In the latter case, users will be able to hit "unshare," then "reshare," which would reset the state as well.

 

What happens when the connection can't be established, will the user be notified or just think he is following the remote by never receive anything?

Synchronization is still going to be an issue that we need to address.  (Sort of a scope greater than the share model.)

 

Will there be a flag indicating if its a bi-directional or a follow contact? Will that flag be switched back if one party removes the connection?

If you're referring to some sort of badge placed on a user's profile that you're viewing, no.  You will be able to tell by whether or not you can send that individual a message, though.

 

Will a contact I'm following be removed from the lists for mentions and conversations so a user isn't trapped on thinking he can and successfully did contact him?

You can only send messages and mentions if you're guaranteed to be able to contact them (via permissions).

 

Thanks,
Jonne

[Daniel Grippi]

On Thu, May 12, 2011 at 7:56 PM, Boon Kiat, Han <wj...@yahoo.com> wrote:

the longer we drag the big launch

the more time the facecrook guys will have to hatch features that they entrench their users with

(@#uckerburg didn't invest in Diaspora to egg us on)

i still think that it will require
- various ports, some minimal (communicating only the least api to not break the network)
- various hosting providers, oversight by diaspora community, to destroy the bar of entry of running server

We're definitely going to work towards lowering the barrier to entry to running a server -- both on your personal machine and on other service providers.

[Ilya Zhitomirskiy]

Hey Diaspora,

Just a quick update, we have to be out of the office today and are going to deploy the share model tomorrow same time (10 am PDT, Tuesday May 17th). We have not merged it into master yet so don't worry if you already did a pull.

Thanks,

Ilya

On 05/12/2011 06:31 PM, Daniel Grippi wrote:

Hello Diaspora,

------- TL;DR

We are implementing a new way to connect to people online. �It is getting rolled out next week. It is somewhere in between a follow and a bi-directional relationship. �When you share an aspect with someone, you start seeing their public posts right away. �If they share back, you have a fully bidirectional relationship.
--------

In a few days, we�ll be upgrading Diaspora�s relationship model to something we call the �share� �model. We believe it�s a more elegant way to connect with other people on the network. �We�ve been working on it over the past month, and we�re happy to announce that it�s ready to go. �Before merging this work into Diaspora�s master branch and deploying this feature onto our on servers, we want to give you a heads up and explain what this new model means to both end-users and developers.

At it�s core, �sharing� is how we�re implementing asynchronous relationships.

Our current bi-directional relationships fall short. They introduce too much friction to exploring all the wonderful public conversations on the Diaspora network (especially for new users). ��New users face a lonely, empty site. �We considered implementing the familiar follow model, but we wanted a system that embraced the asynchronous nature of a follow without losing the benefits of aspects.

For users the interaction is only slightly different:

Putting another user into an aspect means sharing with them. �Sharing includes following; you�ll see another user�s public posts in your stream as soon as you put them in an aspect. ��They, in turn, can immediately see the face that you want to present to them through your profile private posts.

Once two people are sharing with each other, the relationship between the two is exactly the same as what we currently have: �Connected people able to share privately with each other. This allows for more intimate relationships while addressing the �friction� and �loneliness� that we originally found.

For developers not much has changed:

These changes have allowed us to simplify our data model. ��We�re dropping the Requests table and replacing it with two columns in the Contacts table. �Upgrading means pulling and running a migration that will translate the Requests table over to the Contacts table. �That�s it.

For pod-runners:

Since the new model is not backward compatible (although no permanent damage can be done by contacting an out dated pod) on the protocol level, it would be good to upgrade at the same time. We are going to do it at 10 am PDT, Monday May 16th let us know if that's problematic for anyone.

During the time that servers aren�t running the same version, changes in relationships between servers running different versions won�t work, but the upgrade will clear any broken state left in the requests table.

We�ll be happy to answer any questions you might have about this transition.

Daniel & Ilya

P.S. We�ll write a blog post about this in the next couple of days.

[Jason Lewis]

On Fri, May 13, 2011 at 3:51 PM, Daniel Grippi <dan...@joindiaspora.com> wrote:

On Thu, May 12, 2011 at 7:56 PM, Boon Kiat, Han <wj...@yahoo.com> wrote:

i still think that it will require
- various ports, some minimal (communicating only the least api to not break the network)
- various hosting providers, oversight by diaspora community, to destroy the bar of entry of running server

We're definitely going to work towards lowering the barrier to entry to running a server -- both on your personal machine and on other service providers.

I apologize if this has been addressed, but

1) has any thought been given to aiming for Heroku or Engine Yard deployability? 

2) are there Chef recipes for Diaspora server provisioning? 

I think 2) is going to be a huge deal... if a VirtualBox server could be provisioned using Vagrant and Chef, with MySQL all set up and ready to roll so that deploying from the latest master on GitHub is all that needs to happen... that could completely change the 'barrier to entry' situation. VirtualBox image + Vagrant + Chef == easy deploy on your own metal.

I'm working on building an image of my test pod server, once I have something I think looks reasonable, I'll throw it up on GitHub.

Jason

[Tom Scott]

I've been doing some work on Heroku compatibility, but it basically means dropping Jammit altogether. From what I've seen, Jammit requires the ability to actively edit contents in your application directory, which is not possible on Heroku (for obvious security reasons). That's been the major roadblock. I'm working on getting my build (http://github.com/tubbo/diaspora) to function using Rails 3's internal asset cache helpers, in order to allow more people who may not have a lot of Rails or sysadmin experience to get a pod going somewhere. I feel that quick setup will be a VERY important part of Diaspora's future success as a distributed social networking platform. 

However it should be noted that Jammit's asset packaging system seems to be far more advanced and configurable, and we should probably be using it, so I don't think it needs incorporating back into the master repo. Perhaps we should make a "heroku" branch to hold a build optimized for such as service?

-T

[Raphael Sofaer]

We've been working towards postgres compatibility and removing our
non-rails processes. We'll likely want to replace the websocket
server with long polling, for instance. Jammit is an optimization, so
as long as it can be taken out of the project in a smooth conditional
way when it can't be used, don't worry about removing it. I'd rather
not maintain a patchset in a branch, because that takes labor, and I
don't think it will be necessary.

Our chef scripts have gotten stale lately, and they're targeted at
CentOS, which I've been dissatisfied with. I'd like to rewrite them
for Debian, or something else with an up to date libcurl.

Raphael

[Jason Lewis]

Targeting Debian is a good choice, IMHO. After RailsConf I'll try to do a fresh snapshot of a Debian VirtualBox suitable for use with diaspora (and vagrant).

I can't recall, but is diaspora using Modernizr? I feel like ditching websockets is a step back, but maybe reverting to long polling based on feature detection?

Just a thought.

Jason Lewis

Email          jasonl...@gmail.com    
                       
Mobile         414.301.2665

Blog:           http://duckpunching.wordpress.com/

[Evan Burchard]

Are these changes available to pull from github yet? master branch?
follow branch?

-Evan

On May 17, 1:40 pm, Jason Lewis <jasonlewi...@gmail.com> wrote:
> Targeting Debian is a good choice, IMHO. After RailsConf I'll try to do a
> fresh snapshot of a Debian VirtualBox suitable for use with diaspora (and
> vagrant).
>
> I can't recall, but is diaspora using Modernizr? I feel like ditching
> websockets is a step back, but maybe reverting to long polling based on
> feature detection?
>
> Just a thought.
>
> Jason Lewis
>

> Email          jasonlewi...@gmail.com

>
> Mobile         414.301.2665
>
> Blog:          http://duckpunching.wordpress.com/
>
> On Tue, May 17, 2011 at 12:39 PM, Raphael Sofaer

> <raph...@joindiaspora.com>wrote:

[Raphael Sofaer]

The WIP is on the sqllite-compatibility branch.