New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pursue collaboration with gittip.com and gist.io #626

Closed
chadwhitacre opened this Issue Sep 6, 2012 · 3 comments

Comments

Projects
None yet
3 participants
@chadwhitacre

chadwhitacre commented Sep 6, 2012

I dream of a social network focused on productivity. I want to high-volume broadcast my entire day, stream-of-consciousness. Totally open. "I am working on detail X." I did this recently on twitter, when I underwent a bit of a work marathon, and people weren't ready for it. Tweet overload. "Are you going to be tweeting this much all weekend?"

I am of the opinion that rstat.us should focus on becoming its own destination and not focus on being software that anyone can install. See also open companies.

As I think about what I want Gittip to become, I think close partnership with rstat.us and gist.io is the way to go. The project boundary is important, because it honors the decentralization that is at the heart of The Thing. But let's work together. It would be so much awesomer if rstat.us had its own existence and tightly integrated with Gittip than if I tried to add twitter-style shit to Gittip. Same with blogging vis-a-vis gist.io. Let's collaborate! I think this could actually be really, really cool.

The key in my mind is that gist.io and rstat.us are open source, as is gittip.com. Open source meaning not just the code base is developed together, but we can run the destination-sites themselves as open communities. That's new and huge.

I propose a collaboration between gist.io (blogging), rstat.us (micro-blogging), and gittip.com (money) to build a platform for creative work in an open-cultural world.

@wilkie

This comment has been minimized.

Show comment
Hide comment
@wilkie

wilkie Sep 6, 2012

Contributor

I'm not sure this is the best place for this discussion. I'll try to answer sufficiently when I have more than a few minutes, though. :)

My first impression is that I do not understand the idea of 'becoming its own destination' and might need a bit of clarification there. I'll be honest with you, I don't think I'm going to like it. ;)

Contributor

wilkie commented Sep 6, 2012

I'm not sure this is the best place for this discussion. I'll try to answer sufficiently when I have more than a few minutes, though. :)

My first impression is that I do not understand the idea of 'becoming its own destination' and might need a bit of clarification there. I'll be honest with you, I don't think I'm going to like it. ;)

@chrismdp

This comment has been minimized.

Show comment
Hide comment
@chrismdp

chrismdp Sep 6, 2012

Contributor

I guess it depends what sort of 'twitter' stuff you'd like to add to Gittip? I'm not sure that the important thing about rstat.us is the rstat.us site. One of the most valuable things I see that will eventually come from the rstat.us project will be a set of gems that allow any ruby program to behave like an OStatus node without much effort.

That's why I'm keen to work on OStatus support and get it compliant, so that I can embed OStatus-enabled news feeds in my own projects. That way I can publish a stream of news updates on http://soltrader.net without resorting to twitter and allow everyone to subscribe to them from any OStatus client.

For me one of the main interesting things about rstat.us is that anyone can install it with a minimum of fuss, and control their own microblogging data forever. Is this ability limiting what you're imagining for a collaboration?

Contributor

chrismdp commented Sep 6, 2012

I guess it depends what sort of 'twitter' stuff you'd like to add to Gittip? I'm not sure that the important thing about rstat.us is the rstat.us site. One of the most valuable things I see that will eventually come from the rstat.us project will be a set of gems that allow any ruby program to behave like an OStatus node without much effort.

That's why I'm keen to work on OStatus support and get it compliant, so that I can embed OStatus-enabled news feeds in my own projects. That way I can publish a stream of news updates on http://soltrader.net without resorting to twitter and allow everyone to subscribe to them from any OStatus client.

For me one of the main interesting things about rstat.us is that anyone can install it with a minimum of fuss, and control their own microblogging data forever. Is this ability limiting what you're imagining for a collaboration?

@wilkie

This comment has been minimized.

Show comment
Hide comment
@wilkie

wilkie Sep 7, 2012

Contributor

Since you clarified the points I was curious about in #628, I'll answer this along with my response to your discussion there. I take the question of 'Why Do We Do The Things We Do?' very seriously, so I'll probably be a bit long-winded. While my opinions here do not necessarily reflect any of our contributors, what I want everybody to understand is that the process of developing this codebase is to allow for any dream or vision or use-case our contributors and users have. That is, nothing I code should limit the desired use of the codebase for anybody else. Let's get to it.

rstat.us is not a website

Now, this may seem to be a crazy notion that somehow this rails app that gets pushed to heroku is not a website. Let me explain. The thing you see at https://rstat.us is an instance. That is a website. This code isn't a website until instantiated to be one. There may be more than one instance, since it's a distributed system.

rstat.us is a library

So what is it? Think of rstat.us as a library. It's a set of code that you can use to build something else with. It looks like a rails application, which can be a good or bad thing. It does actually have some code that is pulled away from that rigid scaffold, and hopefully more of it can be separated from this project and perhaps gemified. If you want to think of rstat.us the product, you must think of it as a library first. When one writes code or publishes a pull request, the thought of rstat.us being a library drives the discussion.

It is very rare that it is important to say 'https://rstat.us needs this thing.' Interestingly, the website is actually less of a priority now, since users don't seem to want to make use of it through a browser. What they want is a server attached to a domain specific client. However, the UI and UX will of course still be improved because we have awesome contributors that like working on that.

I love, and defer to, @chrismdp's careful wording suggesting that rstat.us gems would "allow any ruby program to behave like an OStatus node." That's what I'm talking about. Programs! Yes! Supersets! And we don't have to limit it to just ruby!

rstat.us provides a community

Alright. rstat.us is a library for building one-to-many server-side instances. Sweet. Why is it important to have many instances instead of focusing on one? Because rstat.us instances belong to a community, referred to technically as the federation.

This community is built off of a protocol. Anybody that implements the protocol is part of the federation. The existing users within the community become your users, and reciprocally any users you bring into the community are users of the other instances.

This protocol is very simple: small pieces of information (your status update, blog entry, new photo) are organized into a feed (typically: atom, rss, etc) and then published to the community. You, a user of any instance that supports the protocol, can choose to subscribe to any other user. You will receive any new posts they make. That's it.

rstat.us is an implementer of this protocol, and thus is a part of the federation. It restricts the content to 140 (this is configurable) character status updates. The strength of this is that rstat.us has hundreds of thousands of users. That will still be true if I fork this project and push it up to my own domain. Furthermore, I can belong to this community and still own my data. It is cooperative, not competitive. We are together as one, by design, and no instance has unfair priority.

If I desire to build an instance with a particular purpose, I can do this. I can add whatever behavior and tweak any setting. As long as that protocol is being used, I'm not interfering with the community. That is, whatever vision of rstat.us I have... I can make that a reality.

_This is why it is important that rstat.us not have any grand ideological ambition other than to be a stable foundation for providing a resource that allows people to own their own data and communicate at large._

what is rstat.us

rstat.us is a library for building server applications that includes an easily hostable website for microblogging within a federated community using the ostatus protocol.

what is an rstat.us user

An rstat.us user can be one of two things, each of which are important.

  1. A developer that uses the rstat.us code to provide their own microblogging service.
  2. Any user of the community at large that communicates through the rstat.us code in any way which include users of services developers create or users within the federated space by an unknown number of instances, services, and codebases.

You can not reasonably:

  1. make assumptions about what a user primarily sees or does.
  2. make assumptions that a user is registered on an rstat.us node.
  3. make assumptions about how a user wants to use any particular rstat.us node.
  4. make assumptions that https://rstat.us is the only or even primarily instance that users use.

response to your issue

Your proposed collaboration cannot be done within the rstat.us space as it violates many of these principles. It would be instead ideal if you added federated support to your site instead. It may be possible to add your idea as an eventual plugin for the rstat.us library, but that's still your responsibility. I cannot change the focus of this project at its core as it would be disingenuous to our contributors.

Furthermore, in no way can rstat.us be it's 'own destination' without crippling it's relationships and strengths. It goes against the very principle of open communication and is rather blasphemous when considering its community. It is actually far more of an open community than the one you seem to propose. You dislike that the technical aspects are being considered before the user experience for the product when you must realize the product is the technical code. That code will be used to create new services and experiences within the same open community.

Your issue is not a bug with this project, and cannot be resolved. At least not here. We will never tightly integrate with anything other than the community at large. It will be possible to loosely integrate at the behest of a node's administrator.

You made many separate points in your issue description, and I hope that I have somehow dealt with all of them and explained the focus more clearly. That said, I'm going to close this issue.

Contributor

wilkie commented Sep 7, 2012

Since you clarified the points I was curious about in #628, I'll answer this along with my response to your discussion there. I take the question of 'Why Do We Do The Things We Do?' very seriously, so I'll probably be a bit long-winded. While my opinions here do not necessarily reflect any of our contributors, what I want everybody to understand is that the process of developing this codebase is to allow for any dream or vision or use-case our contributors and users have. That is, nothing I code should limit the desired use of the codebase for anybody else. Let's get to it.

rstat.us is not a website

Now, this may seem to be a crazy notion that somehow this rails app that gets pushed to heroku is not a website. Let me explain. The thing you see at https://rstat.us is an instance. That is a website. This code isn't a website until instantiated to be one. There may be more than one instance, since it's a distributed system.

rstat.us is a library

So what is it? Think of rstat.us as a library. It's a set of code that you can use to build something else with. It looks like a rails application, which can be a good or bad thing. It does actually have some code that is pulled away from that rigid scaffold, and hopefully more of it can be separated from this project and perhaps gemified. If you want to think of rstat.us the product, you must think of it as a library first. When one writes code or publishes a pull request, the thought of rstat.us being a library drives the discussion.

It is very rare that it is important to say 'https://rstat.us needs this thing.' Interestingly, the website is actually less of a priority now, since users don't seem to want to make use of it through a browser. What they want is a server attached to a domain specific client. However, the UI and UX will of course still be improved because we have awesome contributors that like working on that.

I love, and defer to, @chrismdp's careful wording suggesting that rstat.us gems would "allow any ruby program to behave like an OStatus node." That's what I'm talking about. Programs! Yes! Supersets! And we don't have to limit it to just ruby!

rstat.us provides a community

Alright. rstat.us is a library for building one-to-many server-side instances. Sweet. Why is it important to have many instances instead of focusing on one? Because rstat.us instances belong to a community, referred to technically as the federation.

This community is built off of a protocol. Anybody that implements the protocol is part of the federation. The existing users within the community become your users, and reciprocally any users you bring into the community are users of the other instances.

This protocol is very simple: small pieces of information (your status update, blog entry, new photo) are organized into a feed (typically: atom, rss, etc) and then published to the community. You, a user of any instance that supports the protocol, can choose to subscribe to any other user. You will receive any new posts they make. That's it.

rstat.us is an implementer of this protocol, and thus is a part of the federation. It restricts the content to 140 (this is configurable) character status updates. The strength of this is that rstat.us has hundreds of thousands of users. That will still be true if I fork this project and push it up to my own domain. Furthermore, I can belong to this community and still own my data. It is cooperative, not competitive. We are together as one, by design, and no instance has unfair priority.

If I desire to build an instance with a particular purpose, I can do this. I can add whatever behavior and tweak any setting. As long as that protocol is being used, I'm not interfering with the community. That is, whatever vision of rstat.us I have... I can make that a reality.

_This is why it is important that rstat.us not have any grand ideological ambition other than to be a stable foundation for providing a resource that allows people to own their own data and communicate at large._

what is rstat.us

rstat.us is a library for building server applications that includes an easily hostable website for microblogging within a federated community using the ostatus protocol.

what is an rstat.us user

An rstat.us user can be one of two things, each of which are important.

  1. A developer that uses the rstat.us code to provide their own microblogging service.
  2. Any user of the community at large that communicates through the rstat.us code in any way which include users of services developers create or users within the federated space by an unknown number of instances, services, and codebases.

You can not reasonably:

  1. make assumptions about what a user primarily sees or does.
  2. make assumptions that a user is registered on an rstat.us node.
  3. make assumptions about how a user wants to use any particular rstat.us node.
  4. make assumptions that https://rstat.us is the only or even primarily instance that users use.

response to your issue

Your proposed collaboration cannot be done within the rstat.us space as it violates many of these principles. It would be instead ideal if you added federated support to your site instead. It may be possible to add your idea as an eventual plugin for the rstat.us library, but that's still your responsibility. I cannot change the focus of this project at its core as it would be disingenuous to our contributors.

Furthermore, in no way can rstat.us be it's 'own destination' without crippling it's relationships and strengths. It goes against the very principle of open communication and is rather blasphemous when considering its community. It is actually far more of an open community than the one you seem to propose. You dislike that the technical aspects are being considered before the user experience for the product when you must realize the product is the technical code. That code will be used to create new services and experiences within the same open community.

Your issue is not a bug with this project, and cannot be resolved. At least not here. We will never tightly integrate with anything other than the community at large. It will be possible to loosely integrate at the behest of a node's administrator.

You made many separate points in your issue description, and I hope that I have somehow dealt with all of them and explained the focus more clearly. That said, I'm going to close this issue.

@wilkie wilkie closed this Sep 7, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment