- From: Nick Jennings <nick@silverbucket.net>
- Date: Sun, 2 Jun 2013 03:50:47 +0200
- To: Mike Macgirvin <mike@macgirvin.com>
- Cc: public-fedsocweb <public-fedsocweb@w3.org>
- Message-ID: <CAJL4WtbkcuXxZHKzbrrPf+QLoZ3Ppd39n_BjLO3hRrtLsa4gkA@mail.gmail.com>
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?
Received on Sunday, 2 June 2013 01:51:48 UTC