search

hotsh / rstat.us

Simple microblogging network based on the ostatus protocol.
http://rstat.us/
Other
722 stars 215 forks source link

identi.ca moves to pump.io - how will this effect us? #755

Open jrgifford opened 11 years ago

jrgifford commented 11 years ago

How will this change cause us problems, if any?

Looks like they want to move to another protocol. Does this change things?

http://status.net/2013/01/09/preview-of-changes-to-identi-ca

carols10cents commented 11 years ago

Looks like in uses Activity Streams, which is part of ostatus? I'm really not sure, it would be awesome if someone would do some research to see how pump.io differs from and/or interfaces with ostatus.

jrgifford commented 11 years ago

Right, I'm not sure, hence why I put this up here.

wilkie commented 11 years ago

It simply does pub/sub over activty streams with webfinger for user discovery. It is very similar to ostatus but uses JSON. this is why I am currently working on https://github.com/hotsh/lotus and making it negotiate federation instead of insisting on ostatus. since the data is generally the same, it should be able to handle both. the plan I have is to rewrite the backend as a gem and replace the federation backend within rstat.us with this. I think I can make good progress on this before it becomes a problem.

wilkie commented 11 years ago

Things are going well for the lotus and rack-lotus gem. They are still very much works in progress. This will be a rack-based middleware that will do all of the negotiation and author/feed management. It will expose both the OStatus protocol and the basic ActivityStreams JSON approach used by pump.io. Add rack-lotus to your (ruby sinatra/rails/rack) project, and with a couple of lines of code you automatically have user authorization, feeds/authors, and remote discovery and communication. It will be designed to be easily a foundation for new projects and to augment existing ones.

For rstat.us in particular, the idea will be to get this caught up to and beyond the backend currently within rstat.us, and then... well... replace the backend with this middleware. I will use rstat.us to prove the stability of the middleware. There will be growing pains. And then I want people to build new things beyond rstat.us and for people to stop using the main node. :)

Once this is done, the transition identi.ca aka status.net is taking will not be a problem. (nor anything @evanp chooses to throw at me ;) Nothing in rstat.us exposes OStatus directly... it will operate as it always has. It was part of the "original plan" to gemify the backend of rstat.us, and this is just the motivation I needed to do it.

If anything, the design in rack-lotus is far better than the one I designed for rstat.us. It should be faster and far more sensible to use. Although, hiding the feed models (and even much of the user-auth) inside the gem is kinda weird, it is necessary that the representations and verification of feeds and security, etc, are done in a central, reusable core.

However, this will mean (for better or worse) that rstat.us will simply be the views, view logic, javascript, some backend for status update processing (for hashtags and search,) and design for a federated microblog. Which, I believe, is a far better situation: rack-lotus is for machines... rstat.us is for people.

wilkie commented 11 years ago

I've added embedding (uploading) avatars in Rack::Lotus to get around some of the (horrifying) issues we've had with avatars on the site. That means people using the site will be able to specify their avatar as a url (or pull it automatically from gravatar/twitter/etc) or upload from a file. The avatar is then resized and stored in the mongo database (GridFS) which means no extra requirements. It can be retrieved by either a url '/avatars/:id/48x48' or encoded directly into html with a data:*;base64,* encoding.

When an avatar changes externally, it will be that server's responsibility to ping/send the local node new feed/author metadata so that the avatar can be re-retrieved and updated in the database.

It does mean extra db space requirements. Around 3-4KB for each author discovered by the server. Avatars for people on-site will be a little bigger since it will store a medium sized image for their profile.

I specifically mean to avoid/solve issues such as: #418 #597 #599

chrismdp commented 11 years ago

@wilkie this is awesome. Nice one for pushing ahead with this! Do you have an issues list so we can get involved in lotus or rack-lotus?