Support multiple accounts for each endpoint.

[pjf]

Eg, allow one to have multiple twitter accounts, IRC bots, etc.

This would probably require an expansion of the current configuration system (right now we use .ini files), probably to YAML or JSON configs (to represent the information for each account), and a tweak to our start code to allow all instances to be iterated over. Obviously packet information needs to indicate which account things correspond to.

This is separate from allowing multiple users, which would almost certainly involve separate config directories entirely, and a separate 0MQ bus for each user. (This would be needed for EaaS.)

Suggested by @_aGHz.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1430272-support-multiple-accounts-for-each-endpoint?utm_campaign=plugin&utm_content=tracker%2F347315&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F347315&utm_medium=issues&utm_source=github).

[aGHz]

The first step is probably formalizing the message protocol in such a way that a message can point to things on any server. Referencing could be done via URIs, with message content in JSON-LD. Having a clearly formalized protocol using web standards would increase interoperability between different client implementations.

For example, a Twitter agent running on example.com and connected to the username @example would be referenced via exo:example.com/twitter:example/ and could publish a message containing

{
    "@context": "http://exobrain.org/contexts/twitter.jsonld",
    "http://purl.org/dc/elements/1.1/creator": {"@id": "exo:example.com/twitter:example/"},
    ...
}

[pjf]

Ooh, I've never seen JSON-LD before.

One thing I've had bouncing around in the back of my head is how to do identity management. I'd love for Exobrain to know that @pjf on twitter is paul.fenwick on facebook is pjf.id.au, etc. JSON-LD may be useful in helping present that. (Actual identity mapping would have it's own agent/database, which would query Google Contacts, Foursquare, Facebook, and anything else as appropriate.)

But back to the idea of having multiple accounts, I presume the idea would be to mark up each packet with the creator identifier, and then provide internal mechanisms to:

• Filter on creator (so you can run an agent that only looks at a single account, not all)
• Preserve creator (otherwise we lose information when we turn things like measurements into intents or responses).

[aGHz]

I've been thinking about identity management and I believe it would best be handled by a separate agent that acts as a contact book, linking various identities together. You want this not only for your own identities, but also for those of people you interact with (e.g. you might want to know that a tweet, a FB post and an email actually come from the same person).

---

I actually found something even better: http://activitystrea.ms/ (their IETF draft in particular). It maps cleanly to JSON-LD and is specialized in specifically the kind of data that agents pass around.

The activity+json messages passed around on the MQ would then be written from the point of view of exobrain agents (can we extend the metaphor and call them neurons?), so the 'actor' field would identify the particular agent that injected the message, and the 'author' field would identify the person who originally triggered this agent activity. The other agents could then filter based on pretty much any field defined by activity+json.

(In fact I'm thinking maybe the exobrain message envelope could be an activity+json document written from the point of view of agents, with an 'object' field containing another activity+json document describing the original activity that triggered this. This would free us to use e.g. the 'to' field to list something like interest tags, so the twitter agent would use 'to': ['social-media', twitter'], and other agents could filter on these 'to' values.)

[pjf]

@aGHz : I adore you right now. <3