3 ms·
Ask HN: Open Social Network Systems
Dear Hacker News,
I'm currently building up a internet service that bears a lot of resemblance to the types of things you would see occur on social networking websites, though it itself is not supposed to truly be a social network.
I've been thinking a lot about REST lately, spurred on even moreso by a recent front-page article a man explaining REST to his wife, and I want to implement it in a way that creates a self-describing API with URLs, and is made as open as possible.
My current plans are, at first, not to reveal source code because I don't have a business model (so no plans to make revenue) and I would like some recognition for my team and I if my project is a true success.
However, I still want it to be as open as humanly possible, with all data theoretically machine-readable using the most popular open standards for declaring these objects etc.
This is where the Ask part comes in.. its very hard to look up all sorts of protocols and such for how to implement things, and through that REST article I was able to understand that implementing a separate API - albeit good for business - isn't the way the web is supposed to work.
What technologies should I use for data et al.
Current thoughts:
- Login & Registration (OpenID)
- 'API' Access (OAuth)
- Activity Feeds (RSS, ATOM, some open stream thing?)
- Karma (???)
- Comments (RSS???)
- Profiles (??? RDF or something?)
- Notifications (also RSS..?)
There's so much to think about when it comes to this, and I want my service to not just be a good - but one of the BEST citizens of the Open Web.
So Hacker News, what are your thoughts? What technologies are popular/easy to understand that will encourage openness and cross-communication the best?
Thank you so much.
- mindcrime 15y agoI think you're on the right track, but I'd suggest specifically checking out the Federated Social Web XG: http://www.w3.org/2005/Incubator/federatedsocialweb/ http://www.w3.org/2005/Incubator/federatedsocialweb/ Join their mailing list and participate (or at least lurk) in those discussions to get a feel for what people are doing in this area.
- milkshakes 15y agothe fewer data formats that one has to use to consume your service, the better. i would advise going with REST + JSON, and i would emphasize that your API will live or die based on its documentation. here's a video i found useful that lays out the some basic considerations to keep in mind when designing your API: http://confreaks.net/videos/710-rubyconf2011-advanced-api-design-how-an-awesome-api-can-attract-friends-make-you-rich-and-change-the-world http://confreaks.net/videos/710-rubyconf2011-advanced-api-de...