Re: Federation protocols

On Sun, Jun 2, 2013 at 2:32 AM, Mike Macgirvin <mike@macgirvin.com> wrote:

> On 6/1/2013 12:09 AM, Simon Tennant wrote:
>
>>
>> Instead, think about the tools and services and protocols that solve a
>> real developer problem. We solve this by:
>>
>> 1. Why are developers going to the Facebook SDK pages to build their
>> social products?
>> 2. and what we can be doing to a) understand their needs b) offer an
>> open, hopefully federated, alternative that solves their needs quicker,
>> easier and in a more open way.
>> 3. ???
>> 4. (a higher chance of success).
>>
>
> Bingo.  Thanks Simon.
>
> I see too many people rehashing the same old thing, "social network" this,
> "Facebook" that. If that's what you're building or how you measure success
> - good luck.
>
> I'm working on a nomadic web identity and application framework with
> decentralised "internet scale" access control - which coincidentally has
> the ability to communicate.  That's quite a mouthful and so may not get
> wide adoption precisely for that reason, but you notice that this mission
> statement does not involve "social networking" or "Facebook".  They are
> completely irrelevant to what we are doing. Global (privacy-enabled)
> communications is something that web apps must have going forward. It's in
> our DNA. It probably should be part of yours. It isn't, however, the reason
> we exist.
>
> If we can communicate with/between other projects, it increases the value
> of both projects - as they also build their next big thing. Identity is the
> biggest stumbling block we see, as API federation without identity is not
> really federation.  With simple API federation you would still need an
> account on every service.  That kind of defeats our network-wide
> single-signon.
>

+1


Identity federation is also a hard nut to crack (in our case especially)
> because as mentioned earlier - our identities are nomadic. We can federate
> with other non-Red services as long as our members stay in one place; but
> then they can't experience the full range of what Red has to offer; which
> is the ability to pop up anywhere on the internet on any server and still
> have all their channels and permissions intact (that would be "friends" for
> those of you with more traditional permission models).  This is a tradeoff
> members will have to make on their own if they want their channels to
> interact with non-nomadic services. But passing messages back and forth in
> and of itself is hardly rocket science.
>
> I don't foresee any other projects including a "Red stack".  It doesn't
> fit with their core mission and complicates their identity schema. So from
> the get-go we have to draw a line and say "this person is in-network. This
> other one isn't - you can talk to them, but different rules apply." Which
> brings us back to square one. What are we/you trying to achieve? Federation
> *might not* be the best solution.
>

Do you have a link to this 'Red' project? The name makes it near impossible
to find with a search.

If you have a nomadic web identity solution, I'm all ears. Does it all come
as a package or is the identity portion stand-alone?