How To - Reply
From The Socknet
A message may be posted in reply to any other message or any URL on the Internet.
Contents |
Replying to users and fully-integrated services
A reply is just like any other message, except that it has a reply_to field, holding a message notification (that message notification does not need to have a reply_to field even if it is also a reply).
When a reply is posted, a notification is sent to the provider that hosts the message being replied to. That provider then sends the notification down to all repliers and original recipients of the message. It also sends notification up the tree, if necessary.
POST notify_message
{ ...,
reply_to: {
guid: {
openid: "http://openid.com/user1/",
id: "34"
},
...
},
guid: {
openid: "http://snarkycommenter.com/user2",
id: "3583"
}
}
When a notification of a reply is received, the provider hosting the message being replied to should forward the notification to any other repliers. They should in turn forward the notification to repliers of their messages.
If the message being replied to is a reply, the notification should be sent "up the tree".
Any message host may refuse to forward the notification at its discretion.
Replying to non-integrated or partially-integrated services
To reply to a message from a non-integrated or partially-integrated service requires the same changes in the reply_to field that are normally seen in the guid field.
POST notify_message
{ ...,
reply_to: {
guid: {
url: "http://awesome-funny.com/cat.jpg"
},
...
},
guid: {
openid: "http://laughinguser.com/user4",
id: "355A"
}
}
This notification cannot be sent to the owner of the parent content because it does not support the API. The notification can still be sent to friends.
Considerations
The provider may still use arbitrary criteria to restrict access to the message. The fact that the message is a reply doesn't make a difference.
Consider what happens when UserB replies to UserA and UserC replies to UserB's reply. If UserA and UserC are not friends, and UserA refuses replies from friends, then UserC's reply will go up to UserB, then up to UserA where it will be refused. UserB will still show UserC's reply when users view his profile but UserA will not. UserB will also send the reply down to all his repliers. So everyone that replies to UserB will see UserC's reply, but no one who only replied to UserA will see UserC's reply. This is a Good Thing(tm), but it can cause some confusion. UserC's provider can be aware of all of this through the get_message function, so it should explain the situation to UserC at the time of posting.
Anyone can make replies to display on their own provider about any item with a guid, even if that item doesn't accept replies. These messages will be shown on the replier's profile (and perhaps forwarded to friends), but not the original message writer's profile (or site). These messages are sometimes called "remarks".
Services and providers can use their own rules to decide who can reply to items. But at the very least, they should accept replies from anyone that the item is about, the creator of the item and the immediate friends of those people. That's just fair (this is not a requirement, just a suggestion).
Registered services can reply to items. However, many providers will give them lower precedence than friends (for example, if a list of messages needs to be pared down, the services get hidden first).
Example in which a service replies to items:
Many services will spring up as adapters between the Socknet and existing websites. Keep these things in mind:
- If possible, those other websites should integrate with the Socknet instead of allowing 3rd-party adapters; an adapter is a hack at best.
- An adapter should be very careful about figuring out who can reply to whom. If an adapter can access a message on another website, but cannot post a reply to it, then it should not accept replies from Socknet users.
- An adapter should be capable of determining whether a user on the other website has a Socknet OpenID and use it appropriately. Whenever possible the adapter should identify users' OpenID's in messages.
- Adapters should carefully control the data-flow of replies. The adapter must host a copy of the message and any replies from the non-Socknet website.
- Separate adapters to the same website should look for ways to avoid posting duplicate messages to the Socknet. (This problem is the main reason that adapters are not as good as Socknet providers.)
- Eventually, openid_change will become id_change and adaptor services will be able to give their services to the 3rd-party site owners.
