An activity stream describing an email, and so on.

[Nick Jennings]

Hello everyone.

I'm new to the list, and still learning about activity streams, and
how to use them effectively.

I was wondering what would be the correct way to describe an email
using activity streams. I'm working on a project (sockethub) which
carries out activities from apps via. WebSockets. The protocol I've
chosen is JSON activity streams, and currently what is implemented is
only loosely following the spec. One thing is I'm using the verb
'message' to indicate an actor sending a message to a target. Not a
post (public) but a traditional "private message" ie. email, twitter
DM, facebook message, etc.

The verb 'message' is not defined in the verb list here:
http://activitystrea.ms/registry/verbs/

But, after looking it over, nothing jumps out as me as describing the
action I'd like to represent. Any suggestions or examples?

Here's the ongoing, rough draft of the protocol. So far it describes
search (find user and get profile data), message (send private
message), post (post public text), and there's a rough idea for
presence - subscribe/unsubscribe to a thing or person, to get updates,
ie. subscribe to email (which would send or store new messages as they
come in), or a twitter feed.
https://github.com/sockethub/sockethub/blob/master/doc/api_protocol.txt

feedback, suggestions, questions, all welcome!
Thanks,
Nick

[Chris Messina]

Hi Nick,

Thanks for reaching out. My one concern on the surface is the ambiguity whether "message" should be a noun or verb…! "Send", therefore, seems like a better verb. 

Does either the XMPP or SMTP protocols provide you with any prior art/naming conventions that you could lean on? SMTP in particular might provide you with a better representation of the kind of messaging schema you're looking for...

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To unsubscribe from this group and stop receiving emails from it, send an email to activity-strea...@googlegroups.com.
To post to this group, send email to activity...@googlegroups.com.
Visit this group at http://groups.google.com/group/activity-streams?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
Chris Messina
User Experience Designer, Google

//chrismessina.me | + | @chrismessina

This email is:   [ ] shareable    [✔] ask first   [ ] private

[Nick Jennings]

Hi Chris, thanks for your reply, and sorry for my late reply. Using
send makes sense. I've switched to that.

Not sure if I should start a new thread on this, but I was wondering
what could be used to describe the act of subscribe/unsubscribe? Use
cases:

1. A user wants to receive all incoming emails for their account
'us...@host.com'.

2. User wants to receive all tweets from someone on twitter.

3. User wants to subscribe to an RSS feed of a blog, so gets updates
of new posts.

These actions seem the same to me. Though with email 'poll' is a
common used verb (historically), technically poll can be applied to
all of those cases, since technically that's what's going on. More
generally speaking though, you are 'subscribing' to these things, no?

I read over the verb list and didn't see poll (not sure what the
opposite of poll would be) or subscribe/unsubscribe ... so wondering
if it makes sense to use this, or if it's already been thought out,
and maybe dissected to a point where I didn't notice the verbs that
may apply at a different level?

Cheers,
-Nick

[Chris Messina]

I'd use follow and unfollow for what you're describing. Subscribe is a good synonym, but I think follow is the verb that has become more widely understood/used (in social media).

[James M Snell]

+1 ...follow is pretty much ubiquitous now.

[Nick Jennings]

Follow an RSS feed? Follow your incoming email?
It doesn't really sound right to me, but hey, it'll do. :)
Cheers
Nick

[Chris Messina]

You're following a thread -- wanting to get more from the same source. We deal in synonyms here -- where interop trumps precision, if you can mask that imprecision in the UI. :)

—
Sent from Mailbox for iPhone

[Nick Jennings]

Hi Everyone,

 Sorry to bring up an old thread, but every time I implement functionality in the area of "polling/fetching" for messages with an Activity Stream object, I get stuck with how to use the word "follow"... there's just too much ambiguity.

It was suggested that I use the word 'follow' to indicate that I want to pull in a feed, poll for emails, or whatever the case may be.

*. "follow" an RSS feed (pulls in and parses an RSS feed, 'send'ing objects back to the user)

*. "follow" an email account (using IMAP or POP, polls for messages 'send'ing them back to the user).

*. "follow" a twitter stream   "" ""

*. "follow" a facebook news feed  "" ""

However, this doesn't really make sense, because what about the case where I actually want to "follow" a user on twitter?

There is a difference between "following" a user on twitter and fetching their feed. 

1.In one case I am saying "follow this person" - the action is to connect to the twitter api and issue a 'follow' command.

2. The second is what was the topic of  this thread, relating to fetching and sending messages. In this case I want to get all the latest tweets from a user, it doesn't make sense to use 'follow' here.

Maybe no one wants to invent a new verb, but technically there doesn't seem to be any way to indicate to the program carrying out the task the difference between the two actions.

Essentially the verb would have these same properties (shorthand example):

{

 verb: "follow",

 actor: { address: "http://twitter.com/user1" },

 target: { address: "http://twitter.com/user2" }

}

How does a computer know what action to take? #1 or #2?

Why not add a 'fetch' verb? or something which can indicate "grab any number of new messages" from a source.

Thanks for any insight.

-Nick

[James M Snell]

New verbs are fine, imho. "fetch" seems like a good option.

[Nick Jennings]

Sounds great, thanks James.

Is there any process to register a new verb? 

[Bill Christian]

A new verb might be the best solution. However, I took a step back and tried to understand the purpose of your activity event. From what I understood: #1 is an activity event indicating the actor is now following the target. In the #2 you appear to be instructing an application to retrieve messages from the target. Aren't activity events describing what has occurred? #2 seems to be an action taken by the application as a result of #1 in some business logic layer.

But, this is a concept I am struggling with as well. Does/Should the protocol support API interactions or remain event based solely? 

[Nick Jennings]

Hi Bill,

On Wed, Jun 5, 2013 at 8:17 PM, Bill Christian <bill.ch...@gmail.com> wrote:

A new verb might be the best solution. However, I took a step back and tried to understand the purpose of your activity event. From what I understood: #1 is an activity event indicating the actor is now following the target. In the #2 you appear to be instructing an application to retrieve messages from the target. Aren't activity events describing what has occurred?

I don't think so, from what I understand it, they describe an event. For what I'm doing it makes total sense to use the same object to describe intent, with the option of posting that object as something that happened. Otherwise I'd have to define an API to carry out tasks, and then build the AS object afterward, which would be 99% redundant.

No one sees the object before the service does, so to the code can assume every incoming AS object is intent, and on it's way out it's either a successful or unsuccessful action.

#2 seems to be an action taken by the application as a result of #1 in some business logic layer.

Correct, the project I'm working on, Sockethub [1], uses Activity Streams (albeit loosely at times) to carry out tasks for a user. It's usually used as part of a web app. Most actions are related to messaging in some form and interacting with other people socially (messages, posts, emails, comments, feeds, etc.).

It can be used to build things like web-based email clients, rss readers, instant messaging apps, social feed readers.

But, this is a concept I am struggling with as well. Does/Should the protocol support API interactions or remain event based solely? 

Perhaps someone can clarify?

[1] http://sockethub.org

Cheers
Nick

 

--