Especially errors with calculation of secrets, should benefit from the descriptions of http://developers-hyves.nl/documentation/data-api/content-encoding. If you have problems with secrets, please check our http://developers-hyves.nl/documentation/data-api/oauth-example-code, and see if your code behaves the same way for each example. The examples were taken from http://wiki.oauth.net/TestCases, and most of them serve as unit tests for us.
Another problem that we encountered, is that PHP (or the browser?) translates http://data.hyves-api.nl to http://data.hyves-api.nl/ (note the final slash). If the Consumer calculates the oauth_secret on the basis of an URI without the final slash, and the Service Provider does include the final slash, the secrets will not match. So make sure that you always have your URI end in a slash.
You can use debugging oauth signature calculation.
Contact information (e.g. email addresses, phone numbers) will not be available through the API anytime soon. The idea behind this is that there is a huge difference between allowing my friends to see my email address, and allowing applications logged in as my friends to see my email address. I don't trust my friends to be able to decide which applications they trust with my information.
Looking at it from another way: like the rest of the world I receive a lot of spam. This is because my email address was harvested once by a virus on a computer of one of my friends. So again, if I have friends that manage to install virusses on their own PCs, I'm not going to trust them to only allow benevolent applications to see my email address.
Last part of my argument is that in general contact data is needed to contact people. Even applications with the most benevolent intentions can send emails that are perceived spammy by users (I'm sure you've received your fair share of email that was probably sent with the best intentions, but that you really didn't want to receive). So we don't see how we can share contact data while at the same time protecting our users against spam.
If you want contact information on the logged in member, the best way is to just ask them for their email address. I'm sure if they're willing to share that, they won;t mind typing it in.
The Hyves API allows you to use usernames to retrieve a user. It should be noted that usernames should not be used for anything else. Unlike most websites, Hyves allows users to change their usernames; and they do so regularly. So it would be an especially bad idea to use usernames as primary key for anything; the user with username "john" today, may not be the same as the user with the username "john" tomorrow.
On the Hyves website, the username is not displayed anywhere, except in the URL for the personal overview page. That is why there is no API function to retrieve the username for a user. Although the username can at the moment be deducted from the "url" field of a user, the format of that link may change without notice.
- OpenSocial gadgets can't be placed in groups or hubs (spots, companies, interests, brands, etc). At the moment an OpenSocial gadget is connected to a single Hyver.
- You can't place more than one instance of an !OpenSocial gadget on a profile.
- OpenSocial gadgets can't be placed in scraps, messages, blogs, etc. other then the title and thumbnail in a special format.
A gadget (or 'application') is a piece of code which a user can install on their own profile. A gadget can enhance a users profile and adds to the functionality on the Hyves platform.
We support two main types of gadgets:
This is the current standard for gadgets on Hyves. These gadget are relatively 'smart'. You can retrieve user information and see the difference between the Owner and the Viewer of the gadget. There are multiple social interactions possible, which is preferable for a social network like Hyves.
We do support the YouTube-type gadgets. Simple pieces of code which can not interact with the user itself. These gadgets are therefor considered relatively 'dumb'. When a gadget concept is achievable in OpenSocial we do not allow the gadget as an embed/iframe.
OpenSocial Developer status is a setting on you Hyves account which enables you to set gadgets "Live". Setting a gadget Live means that the gadget is usable on Hyves and can be installed by other Hyvers.
To receive this status you can apply via www.hyves.nl/api/opensocial
Please make sure of the following:
- Ensure yourself that you are using a correct profile
- Make sure you thoroughly tested the gadget on a plain profile in the Sandbox-mode on all views, in multiple browsers
- Make sure the gadget is ready to go Live in your eyes (can you show it to the public?)
- The gadget should follow all policy's and requirements
- Please remember, If you don't like something on your website, we probably won't either on ours ;-)
When you receive OpenSocial Developer status you will be able to use a number of spaces to add Live gadgets. You do not need our approval to do this, as ling as you have space,you can add gadgets.
OpenSocial Developer status is based on trust. With the gadget you send in during the request we test your use of programming languages and user experience. When you break our rules and policy's we can turn of your OpenSocial Developer status and your gadgets.
The OpenSocial standard is a collaboration of Google and other social networking sites (a list of launch partners can be found here: Google OpenSocial Partners).
There are 4 ways to add a gadget.
- By direct linking to the item page (your gadget does not have to be in the gallery for this). Here is an item page example: Buddypoke. You can edit this page when the gadget is added to your live apps www.hyves.nl/api/opensocial This is the only option where you can add parameters to you installation (http://developers-hyves.nl/documentation/opensocial/general-information-limitations).
- By making an API call gadgets.createByXML and adding the original XML-url to this call (note: this is not a different xml for each user, only one gadget url).
- By pressing a "add" or "voeg toe" button at the bottom of the gadget on the profile page or on the canvas page.
- By getting an invite from a friend for the application (aka application invite message).