Re: What we need in a next-gen social network

On Mon, Nov 25, 2013 at 11:45 PM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

>
> On 25 November 2013 23:30, Nick Jennings <nick@silverbucket.net> wrote:
>
>>
>> On Mon, Nov 25, 2013 at 11:24 PM, Melvin Carvalho <
>> melvincarvalho@gmail.com> wrote:
>>
>>>
>>> On 25 November 2013 22:30, Mark Janssen <dreamingforward@gmail.com>wrote:
>>>
>>>>
>>>> It's completely controlled by the user.  However, like all things
>>>> "internet", as soon as you publish something, you necessarily lose
>>>> *some* control.
>>>>
>>>
>>> Ah I see, so the user controls *what* data they put there, but not
>>> *where* they put it.  I'd still perhaps like to see slightly more in the
>>> way of options for the user before I would describe it as "self determined
>>> storage".  I may have bought my own secure data storage area that I'd like
>>> to use.
>>>
>>>
>>
>> I know you're already aware of it Melvin, but just wanted to also mention
>> remoteStorage [1] for the record. The goal of the project is to change the
>> paradigm of web application development and provide a simple client-side
>> library for implementing self determined per-user storage functionality by
>> default.
>>
>> http://remotestorage.io
>>
>>
>>
> Yes am quite familiar with this project and I also like the goals.
> Although it's not a social network it could perhaps become part of a social
> network.
>
> I think it support HTTP verbs such as GET, PUT and DELETE which is great!
>
> Some things I'd like to see to be able to use this library:
>
> A slightly more 'polyglot' approach to identity, so that I could log in
> with my URL profile, as well as the 'user address' concept that this
> library uses
>
> I'd like the library to be able to read my profile using linked data,
> using web standards such as turtle, or JSON and then discovery where my
> storage is.
>
> I've interacted quite a few times with he development team, and outlined
> these requests, if we could get some of these standards supported, that
> could start to be a great candidate for "self determined storage".
>
>
Yup, I'm on board with you here on these things. One of my goals is to make
the client-side JS library a bit more modular, so that the discovery
portion can be extended. You could easily send it a user address or URL and
it will give you back the storage data. This way, even if we initially just
support Webfinger (like we already do) it would be easier to add small
additions to make different types of discovery possible. For these things,
I don't think the spec even needs to be altered, as the JS library would
still behave 100% correct in regards to the spec, just with additional
functionality outside of the scope of the spec.

Using WebID instead of OAuth poses a bigger challenge though.

Like you say, we have a limited amount of resources at the moment, and our
current top priority is stabilizing the library, serious bug-squashing,
increasing our integration testing coverage, and updating it to be
compliant with the latest version of the spec, and a few other features
already in the works. As I'm working full time on Sockethub and web
application development I will have to find some time to really have a look
at this, but hopefully someone else runs with it sooner :)

Cheers
Nick