------- 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<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Diaspora+Sha...>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.
> ------- 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<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Diaspora+Sha...>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.
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.mor...@gmail.com> To: diaspora-dev <diaspora-dev@googlegroups.com> Sent: Fri, May 13, 2011 10:31:11 AM Subject: Re: What we've been working on: Diaspora “Sharing” Model
Sounds like good changes! Thx for the update.
On May 12, 6:31 pm, Daniel Grippi <dan...@joindiaspora.com> wrote:
> ------- 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<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Diaspora+Sha...>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.
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?
> 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?
On Fri, May 13, 2011 at 5:34 AM, Ritchie Wilson <rawilso...@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-rea...@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).
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.
> lets rock this vending machine over > ------------------------------ > *From:* david <david.mor...@gmail.com> > *To:* diaspora-dev <diaspora-dev@googlegroups.com> > *Sent:* Fri, May 13, 2011 10:31:11 AM > *Subject:* Re: What we've been working on: Diaspora “Sharing” Model
> Sounds like good changes! Thx for the update.
> On May 12, 6:31 pm, Daniel Grippi <dan...@joindiaspora.com> 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.
> > 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.
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.
> ------- 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 usersthe 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 developersnot 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 > <http://www.timeanddate.com/worldclock/fixedtime.html?msg=Diaspora+Sha...>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.
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.
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?
On Tuesday, May 17, 2011 at 11:55 AM, Jason Lewis wrote: > 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.
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.
On Tue, May 17, 2011 at 9:02 AM, Tom Scott <tu...@psychedeli.ca> wrote: > 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
> On Tuesday, May 17, 2011 at 11:55 AM, Jason Lewis wrote:
> 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
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?
> 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
> On Tue, May 17, 2011 at 9:02 AM, Tom Scott <tu...@psychedeli.ca> wrote: > > 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
> > On Tuesday, May 17, 2011 at 11:55 AM, Jason Lewis wrote:
> > 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
> 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?
> On Tue, May 17, 2011 at 12:39 PM, Raphael Sofaer
> <raph...@joindiaspora.com>wrote:
> > 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
> > On Tue, May 17, 2011 at 9:02 AM, Tom Scott <tu...@psychedeli.ca> wrote:
> > > 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
> > > On Tuesday, May 17, 2011 at 11:55 AM, Jason Lewis wrote:
> > > 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
On Sat, May 21, 2011 at 9:08 AM, Evan Burchard <evan.burch...@gmail.com> wrote: > 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?
>> On Tue, May 17, 2011 at 12:39 PM, Raphael Sofaer >> <raph...@joindiaspora.com>wrote:
>> > 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
>> > On Tue, May 17, 2011 at 9:02 AM, Tom Scott <tu...@psychedeli.ca> wrote: >> > > 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
>> > > On Tuesday, May 17, 2011 at 11:55 AM, Jason Lewis wrote:
>> > > 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
