gaurav bhatia's List: Social Networking Docs

• There are no limits to how many friends a user can invite.
• A user can only receive an invitation to an application from the same friend once.
• Notifications can be sent to users who have the application installed and users who don’t have the application installed as yet
• Notifications will be limited to 5 per application per recipient per day, and a maximum of 100 recipients will be allowed per request.
• he notification will only be sent to recipients that either have the app installed or are friends with the viewer.
• Applications can send email messages to users as long as the user has the application installed and the user has given the application the permission to do so.
• Currently, the e-mail limit is 1 email message per app per recipient per day. The user will have the option to unsubscribe from the email message.
• Currently we support 1 update at any given time per generating user per application, meaning a user could see at most the same number of updates on their homepage from an application as they have friends. We plan on supporting activity templates in a follow-up release, which will allow for better matching and aggregation and will allow us to change this limit.

6 more annotations...

• Which users a user can write Persistence data to is a policy decision that  is made by each OpenSocial container. Currently, the "default" policy that  most active containers have implemented is that an application can only write to  VIEWER data, and only if the VIEWER has the application installed.   This policy is fairly restrictive to prevent   malicious users from writing data to arbitrary users, so it  is expected to be the most commonly implemented Persistence data policy.   This article was written under the assumption that data will only be   writeable to VIEWERs with the application installed, and presents   advice on how to structure applications around this limitation.

     

  It is certainly possible that some containers may implement  a more relaxed data policy that allows users to write data to other users'   Persistence data. Additionally, some containers may choose to give their   users the ability to set ACLs on their Persistence data. In this model,  a user would be able to whitelist other user accounts to read from or write   to their own Persistence data.

• Character escaping

    

  Since application data is visible to more than just the user who writes it,   there is a danger that any given application data may contain content from   a malicious user. For this reason, the OpenSocial specification stipulates   that application data must be HTML escaped by the container before being   returned to the application.

    

  This will prevent situations where application data output without being   filtered by the application first. Consider the following data string:

    

  "<img style=\"width: 1; height: 1;\" src=\"adsfa\" onerror=\"alert('hello')\" />" 

    

  If the above string is put directly into the innerHTML   property of a page element, a popup box containing hello will be   displayed. While this sample is harmless, allowing JavaScript from other   users to execute without being filtered is a security risk. Therefore, if   that string is stored in application data, it will be returned as:

    

  "<img style="width: 1; height: 1;" src="adsfa" onerror="alert('hello')" />" 

    

  which, if put into the innerHTML property of an element, will   simply print the <img> tag and the alert() code, instead of   executing the JavaScript directly.

    

  If you need to undo this encoding operation for some reason, you may use   the gadgets.util.unescapeString function to return the escaped   string's original form. Be careful about displaying unescaped data, though,   for the reason explained above.

• Quotas

    

  Social applications may potentially be used by millions of users, and   unchecked use of application data stores may put a large storage burden on   containers. It is expected that most containers will therefore implement a   data storage quota which applications may not exceed. This quota will   usually be measured as being a certain number of bytes per application   per user.

    

  When writing application data that would exceed the size of the current   quota, the write request will fail and the container will return an error   message indicating that the limit was exceeded.

• Viewer data is the cornerstone of the Persistence API. All data must be   written through VIEWER, which means that users cannot change application   data for anyone but themselves.

    

  While you can read data written to VIEWER by getting OWNER or OWNER_FRIENDS   data in different contexts, directly reading VIEWER data is really only   useful for storing application preferences that need to travel with the user,   instead of the profile on which the application is installed.

• If I can't set OWNER data, who can?

    

  Well, the VIEWER can when the VIEWER is the same person as the OWNER.   To set OWNER data, an application simply writes to the VIEWER data store   for a user who has the application installed. This data is available as   OWNER data on that user's profile.

     

  Who can see OWNER data?

    

  As long as an application is installed on someone's profile, OWNER data   will always be available, no matter who is looking at the profile.

• What uses are there for OWNER data?

    

  By setting and getting OWNER data, an application can let each of its   users customize the way the application works on their profil

4 more annotations...