-
Notifications
You must be signed in to change notification settings - Fork 53
Talk page
This page is dedicated for any talk. Feel free to leave any comments, feature requests, and exchange ideas.
coderwall.com/workforpie.com/geekli.st These 3 sites are the examples of Github api.
btw: recommend coderwall.com for you.
I'm not familiar for the following three sites. For Github and Googlereader, I think it's worth our attention.
I was heavy Google reader users before. It will be very nice if I can import feeds (like new statuses) from this big aggregator. Then I can use same ranking function to prioritize them, seaminglessly. Currently, my solution is to export from Google reader and convert it into SNSAPI's "channel.json" format. It takes time to poll all the feeds (hundreds of them). Although SNSRouter can provide a level of asynchronous aggregation, it will be better off for normal users if we let Google aggregate and only run user specific logic locally (filtering, ranking, etc).
Many thanks for bringing them to our sight. I just added a dedicated wiki page for coordination on this matter.
https://github.com/hupili/snsapi/wiki/Wishlist-of-new-platforms
I think we can even implement Github api , It's very useful for some new concept websites, suce as coderwall.com / workforpie.com / geekli.st . This kind of sites will appear in China in some days. It will be useful.
How about add support for GoogleReader , I like GoogleReader very much , and I tried to implement it in Java. Having some experience.
TODO list:
- An example to help users jumpstart
- Read configurations from file, instead of writting in '.py' file. (avoid commiting in those secrets by mistake... used to happen in another project...)
- Upgrade '.gitignore' file to avoid commiting in non-source files. (e.g. '.pyc')
(brainstorm)
Thoughts after 1st successful test:
- Abstraction of channels, provided by plugin script files.
- Realization of channles, provided by configuration files.
We construct a user story based on this flexibility:
- He watches three blogs regularly.
- He has two Sina Weibo accounts.
- On one account, he follow IT news and share them with his friends.
- On the other account, he follow gossips and share them with his friends.
- The three blogs update high quality content frequently.
- He forward those blog posts to his two accounts according to their category. (maybe using 'long weibo' tool).
{
"channel_name": "sina_account1",
"platform": "sina",
"app_key": "",
"app_secret": "",
"user_name": "sample_name1",
}
{
"channel_name": "sina_account2",
"platform": "sina",
"app_key": "",
"app_secret": "",
"user_name": "sample_name2",
}
{
"channel_name": "blog_feed_1",
"platform": "rss",
"url": "sample_url1",
}
{
"channel_name": "blog_feed_1",
"platform": "rss",
"url": "sample_url2",
}
{
"channel_name": "blog_feed_1",
"platform": "rss",
"url": "sample_url2",
}- "channel_name" is the identifier of a channel.
- "platform" gives the abstraction name of a channel. The notion is very like "class" name in OOP. So a channel can be understood as "instance".
- Other fields are "platform"-specific.
Reply for 20120709.hupili
Good job!
User may have several accounts in one platform. The configuration file for user is a good idea. but APP_KEY and APP_SECRET should not be seen by users, so I think APP_KEY should be placed in "plugin script file", being part of the ultimate binary code when distributing. One platform be given one APP_KEY is enough.
so I think the user configuration file will be like:
{
"channel_name": "sina_account1",
"platform": "sina",
"user_name": "sample_name1",
}I like the conception of channel. Different platforms just like different local area networks, when we put channels between them, then information flows even wider. But information may attenuate when transfering from one platform to another.
The vision will be put into more formal wiki sections. Before we finalise it, I just record some clues in this page. Please help to elaborate the statements. :)
Why do we need a short description of vision? I think we all have limited time, so attracting more people is necessary towards a real successful system. There are possibly three ways to get people engaged:
- Use monetary methods.
- Impose pressure.
- Share the vision.
Here's a list of where we start and how/why we reach this project:
- Current SNS is centralised.
- Problem1: one SP have all users' data --> privacy concern.
- Problem2: single point failure --> block the domain/IP of Facebook and everything is gone.
- The solution to both: a decentralised SN.
- Choices: distributed design; federated design; etc.
- Think wilder: an overlay network upon all means of communications! That is, unless one is physically isolated he won't be an island in the Internet. He can use SN functions as before. All underlying communications are transparent to the user(or say the app layer developers). When talking about all kinds of communications, we mean: Micro Blogs, SNS, Email system, other Internet protocols, NFC/D2D for mobile devices ==> as long as human mobility is not constrained, information will pass on.
- Think backwards: we need to implement something first to prove the concept.
- Unifying SNS APIs will be a good first attempt!
- Problem: there are so many APIs, in different flavour. Maintaining burden is too high.
- Solution: a middle ware! Just like LLC's position in the network stack.
- What to do: a carefully designed framework(snsapi); several workable means of communications(plugin); proof of concept(app).
Very good summary, I can see the steps we take till we are here.
Where our vision step on. I'd like to explain the hierarchy of snsapi which has 4 layers.
- Application layer : Container of channels, forwarding tools, multi-platform update, etc.
test.py test-channel.py
- Interface layer : API name and arguments, Information format.
snsapi.py snsType.py
- Channel layer : Different platforms or channels plugin, implement what interface layer assigned.
plugin/sina.py plugin/qq.py
- Physical layer : HTTP, REST, open Authorizing, data storing and other tools.
snsapi.py oauth.py utils.py
I have to say, the API is so geeky. Once you know something about programming, you can easily build a real application upon it. We're going to make it even easier.
First app, forwarder is deployed on a server. The authentication period lasts as long as cookie timeout (I'm not sure what's the cookie timeout value).
Another purpose of this message is to trigger a wiki page RSS update. I expect my server to forward this update to Sina.
I has been running for a whole night. Looks good. Trigger a wiki page RSS update again. I'm ready to configure more feeds then.
I come to trigger an update again. The news should be forwarded to both Sina and QQ this time~
I come across another interesting project: http://pipes.yahoo.com
Their notion is more close to what we are trying. I haven't fully tested the Yahoo Pipe. To my current knowledge, it is developing into a programming language for mass audience. Another analogy is the Scratch http://scratch.mit.edu/. The contribution is that, non It professionals can manage to write their own logic. Yahoo Pipe, which intends for piping the Internet, have many useful building blocks.
It's an interesting trial towards better information processing for human. I'm just wondering how many people can really manage to make full use of it. Like for Scratch, the man who manage to write a good Scratch program may already be well trained for at least one "real" programming language. However, the real programmers will hate dragging pieces of "modules" in the browser and filling in the parameters.
Again, I think this platform is also worth a try. At least, simple bridging rules can be configured there and they already have many workable "channels". Our work can enable finer-tuned rules and fit the geek's appetite.
Renren Xiaozhan has developed into a similar form of overlay social network.
- It's an application on Renren and now have corresponding app on Sina, QQ, Douban.
- When you share something on Renren Xiaozhan, the news is synchronised to news feeds of all the platforms.
- Authorising this app on QQ does not require password input(when the cookie is valid). I think they have profound cooperation to smooth this process.
The project page: http://code.google.com/p/blogs-to-wordpress/
This project is one recent active project. Looks good.
In the channel terminology, it must have the ability to read the blog of baidu, 163, QQ, etc. It can at least write to wordpress. There are also requests in her blog posts asking for support of synchronising contents from wordpress to the other platforms. If this is implemented, there will be many new channels. Hope the data structure she use is easy to integrate.
http://wiki.opensns.qq.com/wiki/%E3%80%90QQ%E7%99%BB%E5%BD%95%E3%80%91API%E6%96%87%E6%A1%A3
I get the prompt from Pengyou.com of Tencent today. It seems they have migrated the original Xiaoyou.com data to the new domain. I get astonished that my recent QQ status updates are synchronised to Pengyou.com. Similar thing applies to qq-zone. I can not get a clear picture of what is synchronised to what in a glimpse. They have so many sub-platforms, partly connected. It's a burden for users to distinguish between them. What can/cannot be posted at some place?
Then I looked at their open API. Tencent is only one in China who has full product chain: micro-blog, social network, electronic payment. Their API seems to integrate all the components. Their documentation also reads better than Renren's.
Here's the geek stuff... https://github.com/lukaszkorecki/earthquake
I clone the snsapi.wiki repo and modify locally. Then I test push the new version to our wiki.
See the following link: https://www.pivotaltracker.com/
I just got to this from Diaspora project, which is the currently most successful decentralised social network implementation.
Pivotaltracker looks fancy. I'm not very used to it. Note it here, in case we need it in the future.
Here's one SN bridging component. http://duoshuo.com/
They use the api of different SNS. Currently they focus on lowering the barrier for people to leave comment at the blogs. There is much ore they can do.
Example. If you bind twitter account to linked-in, they'll work through a linked-in app. In this way, the app is able to forward information between the two platforms. They have such choice: add a tag "#in", then it will be auto-forwarded.
I can think of some features to use:
- Link relationship. Where does this message come from?
- Special tag?
- Location?
- Time?
- Content? Or more advanced, use wordnet to mine upper level.
Moved from Issue #12.
It's also time to add the license. One recommendation. http://unlicense.org/
I got to know http://sam.zoy.org/wtfpl/ before the unlicensed. WTFPL is very sharp literally.
I don't like reading the long descriptions of many licenses(like GPL, MIT, etc). It's a waste of time doing so. Such license strings never stop real bad guys. How can you know someone else is using your work? Such strings do bother many legitimate users. They slow down the rate people creating new stuffs. WTFPL is the sentence I want to say. Unlicensed is one formal-looking license I'd like to adopt(one phrase and a small sign).
What do you think?
In the 2nd mile(restructuring, container, cli), we may not see a wide audience. So the current situation is "OK". Before it goes too big, we should leave a formal statement of license there, to embrace a larger group of users. We also have to check those 3rd-party modules. Do they conflict with Unlicensed? I remember some license state its inheritance in a recursive way. Say, if you use something under L license, then its children are all under L license (F...).
If the inheritance is stated, there are three ways:
- Do as they wish. The worst is to change license.
- Find no-inheritance alternatives.
- Remove their files. State the interface(xxx is what we need). Leave a pointer to the original thing. Users can choose to build the modules according to our interface specification; Or they just download from the link themselves(that module is not in our project, the integrated version is the user's project)! Whether the user regard the integrated project as Unlicensed or not, we do not care.
- https://github.com/liluo/py-oauth2, it's an updated package for OAuth2.0 .
- https://github.com/simplegeo/python-oauth2, it actually implements OAuth1.0 . python-twitter project uses this implementation.
- email. standard.
- libiamp. standard.
- libsmtp. standard.
- libgmail. http://libgmail.sourceforge.net/
- email API for GAE. https://developers.google.com/appengine/docs/python/mail/
Note a very close software:
It's a Chrome plugin. It supports many OSN (narrow-sense SNS). It has a medium user group now.
In terms of frontend design, we can learn much from them.
- Yonoo: Aggregation service; closed system; provide browser plugin and native app of smartphone; mainly oversea sites like FB, Twitter, etc.
- SocialOomph: Seems only for Twitter(?); focus on intelligence (user discovery, scheduled updates, etc); Only web service.
- Hootsuite: Aggregation service; provide certain intelligence; only web service.