Skip to content
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

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

Open
jrgifford opened this issue Mar 27, 2013 · 6 comments
Open

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

jrgifford opened this issue Mar 27, 2013 · 6 comments

Comments

@jrgifford
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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

@wilkie
Copy link
Contributor

wilkie commented Mar 27, 2013

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
Copy link
Contributor

wilkie commented Apr 3, 2013

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
Copy link
Contributor

wilkie commented Apr 9, 2013

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
Copy link

chrismdp commented Apr 9, 2013

@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?

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

No branches or pull requests

4 participants