
Global Task Exchange Protocol - madospace
https://github.com/madhugb/Global-Task-Exchange-Protocol
======
smoyer
I would suggest this is the perfect example of a project which should extend
SCIM [1], a recently release RFS for this functionality. SCIM is Simple Cross-
domain Identity Management and allows sharing of user and group information
via RESTful JSON APIs. It's easily sufficient for vCard information and is
also easily extensible. I think calendar and to-do information is the next
step.

[1] [http://www.simplecloud.info/](http://www.simplecloud.info/)

~~~
madospace
Amazing, I think if we keep identity management as a part of configuration
then it will be easier for development, till one protocol becomes standard. I
will try to add this as a default identity management. Thanks for the link.

~~~
smoyer
Our group is responsible for building and maintaining 108 applications. We
were tired of building user-permission systems into every application, so
standardizing our user and group system around SCIM solved half of the
problem. For a standardized way of managing roles-permissions, we've adopted
the ANSI RBAC [1] standard. The Apache Directory project's Fortress [2] sub-
project is compliant with the ANSI RBAC specification and also implements
ARBAC principles for role and permission administration.

The final piece of our centralized Authentication and Authorization strategy
is a security server that allows a client with an OAuth2 Bearer token to
access the user-group system, role-permission system, and to authenticate to
our applications on behalf of a user using JWT. We're still working on a UI
that will allow delegated administration (we've got 200k active users to
manage) so that a manager will be granted the right to administer certain
roles-permissions and it's then their responsibility for making sure their
employees have the appropriate permissions.

We're in the process of adding ABAC style permissions so that we can manage
user access in n-dimensions while slicing data (an employee might be allowed
to manage financial data per the RBAC roles they're assigned but we also need
to make sure they can only charge expenses to accounts that they're
responsible for and potentially to apply limits to what they can spend without
higher approval).

The first parts of our system are functional and we'll be rolling several
applications with simpler permissions out over the next two months. We've
actually been thinking about this problem for over three years, implemented
the first of the ANSI RBAC roles over two years ago and we're finally getting
the last pieces in place to make the whole system work. The only outstanding
question is whether we can create a centralized UI for managing ABAC controls
since these controls commonly require the context of the external application
to make any sense.

In any case, I hope the two links below help!

[1] [http://csrc.nist.gov/groups/SNS/rbac/documents/draft-rbac-
im...](http://csrc.nist.gov/groups/SNS/rbac/documents/draft-rbac-
implementation-std-v01.pdf)

[2]
[http://directory.apache.org/fortress/](http://directory.apache.org/fortress/)

P.S. I should also mention that the system that's been running for two years
now provides RBAC for over 3M users with our non-privileged accounts.

~~~
madospace
User roles-permission is indeed a complicated problem to solve. But do you
think this will need so much complication?

As far as I think, it is straight forward. But I also agree when you work in a
complicated hierarchy, you probably need these systems.

~~~
smoyer
No ... I don't think you would need roles and permissions for the task project
but since you were enthusiastic about the user and groups I thought I'd pass
along a solution for a comprehensive (but external) user management system.

EDIT: I also should have mentioned that we're updating our original system to
be compliant with the specification and open sourcing [1] the code that's not
custom to our application.

[1] [https://github.com/PennState/scim](https://github.com/PennState/scim)

------
cjp
An ambitious idea. Some questions immediately spring to mind.

> Task is owned by a Project. Project belongs to a User. User is a member of
> Domain.

Can Tasks have subtasks? Recursively? To an arbitrary depth?

Can Projects have subprojects? (see above)

I assume since a "User" is just an email address, a group email address would
implement a "Group" at the "User" level?

In a company setting, Users (Contractors, Employees) come and go during the
life of a Project. What happens to Tasks assigned to a User who leaves the
(company|Domain|Project)?

~~~
madospace
So any task with `Parent-Id` will be a sub-task. If User owns the tasks he can
see the subtasks tree also. but if you own the sub task alone, for you it is
like a normal task with an out of scope parent.

Recursive tasks works exactly like recursive calendar events.

I have not thought about Sub-Projects, any suggestions?

User-Group - That is interesting, I think it should not change the behaviour
based on the Type of email, which is difficult to determine.

When a user leaves do the same thing as email - either purge them all or re
assign it to someone else.

~~~
cjp
> So any task with `Parent-Id` will be a sub-task. If User owns the tasks he
> can see the subtasks tree also. but if you own the sub task alone, for you
> it is like a normal task with an out of scope parent.

That should work.

> Recursive tasks works exactly like recursive calendar events.

I'm not sure what a recursive calendar event is. Are you reading "recurring"
instead of recursive?

> I have not thought about Sub-Projects, any suggestions?

The same `Parent-Id` solution as subtasks should also work here.

~~~
madospace
> I'm not sure what a recursive calendar event is. Are you reading "recurring"
> instead of recursive?

yes! sorry i misunderstood. and now we have solution to both recurring and
recursive!

> The same `Parent-Id` solution as subtasks should also work here. Yes, it
> will - but does it complicate the architecture ?

------
epaulson
I'd follow along with what the IndieWeb folks are doing. They've got a pretty
good principle of reusing existing infrastructure in new ways to build
interesting things without needing coordinated upgrades.

As an example, getting widespread adoption of a new TX DNS record type is
unlikely, though you can fake it with TXT records.

[https://indiewebcamp.com/Category:building-
blocks](https://indiewebcamp.com/Category:building-blocks)

~~~
bartbes
It sounds to me like the OP is actually looking for SRV records, which are
basically generalised MX records.

~~~
madospace
For now TXT records will work, till it becomes a stable one, then it can be
moved to either SRV or its own set of records

------
fiatjaf
The idea is great. Perhaps, however, it is too ambitious.

Maybe this could start as a thinner protocol, with adaptors to turn Todoist,
Asana, Trello and Basecamp into clients.

~~~
madospace
Of course. I am starting a basic implementation with asana hook.

------
secstate
As someone who uses Todoist for personal tasks, Asana at work, and Basecamp
for those clients who haven't migrate to Asana yet ... yes.

From a pragmatic perspective, I'm not sure this can gain traction. The mail
exchange protocol was built in a very different environment, and you'd have to
get some serious weight behind this to gain much traction.

~~~
markonen
It does seem unlikely to that something like this would gain traction among
existing task-oriented apps and services, but perhaps that's not the point.

To me, the more intriguing question is this: what sort of _new_ task
management apps could and would get built on an interoperable platform?

One end result of the lack of interop in this space is that commercially
viable task management apps trend toward being all things to all people. There
is a legitimate need to satisfy a very wide variety of use cases.

If task management apps could interoperate on a common set of data, it might
become feasible for much more narrowly scoped, purpose-built apps to succeed.

~~~
madospace
Actually most task management systems allow that today, through APIs, but you
will need some glue to fix them together, like IFTTT or Zapier.

This is not limited to interoperability, cross domain / organization
collaboration tool. It is almost like asking what sort of e-mail tools can be
built on top of email protocol.

You are right about the commercially viable aspect. But if I wanted to make it
commercially viable I would not have made it open.

I think something like this WILL be the `interoperate` set of data that you
are talking about.

------
d33
> Use private and public keys encryption

Yeah, sounds trivial.

~~~
bluecmd
My thoughts exactly

------
thomasdd
Had the same idea couple of times, whet I needed to distribute tasks between
couple of servers. Now I can imagine it, as some sort of TCP service (like
EMAIL) powered by DNS records and TCP server/client. Maybe SMTP can be also
used. This desires and requires more time and energy, maybe a team of people,
maybe open standard and SW implementation of TCP services. This could be used,
not only for humas, but also for automation.

~~~
madospace
I wonder if this can work for task distribution. Certainly the idea of using
these bytes of information to automate few things, of course yes!

------
michaelmior
What is the use case? (Ideally, use cases -- plural.) I can sort of
extrapolate from what is written but it would be great to have that clearly
stated.

~~~
madospace
Good point, I will be adding them shortly.

For example \- Project management involving multiple Organization. \-
Freelancers to work closely with the team \- Open source Project development

------
skybrian
I'm not getting what this is for. It seems to be something about automation
around arbitrary people on the Internet giving you work to do. It seems like
this is a flaw to get rid of? Email and bug trackers make it all too easy.

~~~
madospace
Partially I agree with you. This is to get rid of the hacks people do to work
across organization wall.

Let me try to explain: A task is not just a text, it has context and history,
and meta data. Unfortunately people use email for this which creates 100s of
messages in a thread. Instead, if you keep single entity and keep updating it
like you would do in any task management system, it will create better meta
data and less headache to manage.

~~~
skybrian
Okay, but switching to a better issue tracker (for your needs) seems
considerably more practical than solving data interchange between issue
trackers.

