librelist archives

« back to archive

remotestorage separation from unhosted

remotestorage separation from unhosted

From:
Jan-Christoph Borchardt
Date:
2012-09-12 @ 19:21
We talked a lot about the relationship of unhosted and remotestorage
in the past, and at the Unhost unconference finally with more people
than just Michiel and me. We concluded that since we introduce 2
technical concepts to people which do not necessarily need to be
connected, we should separate them more clearly. While there is lots
of possible overlap and remotestorage was born out of the then
Unhosted project, we should have 2 strong separated brands also to
avoid confusion what is what.

»unhosted« means client-side web apps, written in Javascript, HTML,
CSS (check http://unhosted.org )
»remote storage« means per-user storages which use OAuth, CORS &
get-put-delete (adhering to
http://w3.org/community/unhosted/wiki/RemoteStorage )

That is, unhosted web apps can work without remotestorage. They can
just use localStorage, or they can use Dropbox, Google Drive, iCloud
or any other storage standard. Although remotestorage for now is the
recommended open standard because it is standardized, interoperable
and can be deployed by anyone.
And remotestorage can be used by more than just unhosted web apps. We
talked to people of Libre Office and Thunderbird before, and in
presentations have always said that the web apps do not necessarily
need to be client-side only. But unhosted web apps are recommended,
since they are platform-independent, portable and do not track you.

So let’s go! We have a new Github organization at
http://github.com/remotestorage – I already added some people involved
with remotestorage, and the remotestorage.js repository moved there
from unhosted.
Join our IRC channel #remotestorage on freenode.net and the mailing
list is kicked off with this post – join by mailing to
remotestorage@librelist.com, the archives will be available at
http://librelist.com/browser/remotestorage/
Also follow https://twitter.com/remotestorage_


Freedom from the web’s monopolies!

Re: remotestorage separation from unhosted

From:
Jan-Christoph Borchardt
Date:
2012-09-12 @ 19:24
So what do we have?

app libraries:
https://github.com/remotestorage/remotestorage.js (Javascript)
https://github.com/lukashed/remoteStorage.py (Python)

remote storages:
https://github.com/owncloud/core (PHP) used by http://owncube.com
https://github.com/fkooman definitely has some, not sure which repo
though ;) used by SURFnet
https://github.com/5apps/liquor-cabinet (Ruby) used by http://5apps.com
https://github.com/pagekite/plugins-pyUnhosted (Python) used by
http://pagekite.net
https://github.com/jcoglan/restore (Node.js)
https://github.com/5apps/express-storage (Node.js) possibly deprecated
https://github.com/mk-fg/django-unhosted (Python)


Do we fork them to the remotestorage Github organization? Or do we ask
the authors if they want to transfer ownership to remotestorage, in
which they can continue to develop them there? Or do we do nothing at
all, just maybe linking to them?

I think asking the authors to transfer ownership is best (except
ownCloud, which is not a dedicated remote storage only). Those which
don’t want to do that we’ll still link, but it’s best to have it under
one umbrella because it’s all about the same standard.

CC’d the authors – please let us know your stance on this.




On Wed, Sep 12, 2012 at 9:10 PM, Jan-Christoph Borchardt
<hey@jancborchardt.net> wrote:
> We talked a lot about the relationship of unhosted and remotestorage
> in the past, and at the Unhost unconference finally with more people
> than just Michiel and me. We concluded that since we introduce 2
> technical concepts to people which do not necessarily need to be
> connected, we should separate them more clearly. While there is lots
> of possible overlap and remotestorage was born out of the then
> Unhosted project, we should have 2 strong separated brands also to
> avoid confusion what is what.
>
> »unhosted« means client-side web apps, written in Javascript, HTML,
> CSS (check http://unhosted.org )
> »remote storage« means per-user storages which use OAuth, CORS &
> get-put-delete (adhering to
> http://w3.org/community/unhosted/wiki/RemoteStorage )
>
> That is, unhosted web apps can work without remotestorage. They can
> just use localStorage, or they can use Dropbox, Google Drive, iCloud
> or any other storage standard. Although remotestorage for now is the
> recommended open standard because it is standardized, interoperable
> and can be deployed by anyone.
> And remotestorage can be used by more than just unhosted web apps. We
> talked to people of Libre Office and Thunderbird before, and in
> presentations have always said that the web apps do not necessarily
> need to be client-side only. But unhosted web apps are recommended,
> since they are platform-independent, portable and do not track you.
>
> So let’s go! We have a new Github organization at
> http://github.com/remotestorage – I already added some people involved
> with remotestorage, and the remotestorage.js repository moved there
> from unhosted.
> Join our IRC channel #remotestorage on freenode.net and the mailing
> list is kicked off with this post – join by mailing to
> remotestorage@librelist.com, the archives will be available at
> http://librelist.com/browser/remotestorage/
> Also follow https://twitter.com/remotestorage_
>
>
> Freedom from the web’s monopolies!

Re: remotestorage separation from unhosted

From:
Martin Stadler
Date:
2012-09-12 @ 19:39
We also have http://remotestoragejs.com which is not a good fit for the 
whole project. We're trying to get remotestorage.org or, if that doesn't 
work out, remotestorage.io to put up a website for everything around 
Remote Storage, like

* description of the technology in general (linking to unhosted.org for 
describing the goal of unhosted web apps that we try to achieve
* spec (probably only linking to W3C)
* everything about storage
* everything about apps (clients)
* dev team
* ...


Am 12.09.2012 um 21:24 schrieb Jan-Christoph Borchardt:

> So what do we have?
> 
> app libraries:
> https://github.com/remotestorage/remotestorage.js (Javascript)
> https://github.com/lukashed/remoteStorage.py (Python)
> 
> remote storages:
> https://github.com/owncloud/core (PHP) used by http://owncube.com
> https://github.com/fkooman definitely has some, not sure which repo
> though ;) used by SURFnet
> https://github.com/5apps/liquor-cabinet (Ruby) used by http://5apps.com
> https://github.com/pagekite/plugins-pyUnhosted (Python) used by
> http://pagekite.net
> https://github.com/jcoglan/restore (Node.js)
> https://github.com/5apps/express-storage (Node.js) possibly deprecated
> https://github.com/mk-fg/django-unhosted (Python)
> 
> 
> Do we fork them to the remotestorage Github organization? Or do we ask
> the authors if they want to transfer ownership to remotestorage, in
> which they can continue to develop them there? Or do we do nothing at
> all, just maybe linking to them?
> 
> I think asking the authors to transfer ownership is best (except
> ownCloud, which is not a dedicated remote storage only). Those which
> don’t want to do that we’ll still link, but it’s best to have it under
> one umbrella because it’s all about the same standard.
> 
> CC’d the authors – please let us know your stance on this.
> 
> 
> 
> 
> On Wed, Sep 12, 2012 at 9:10 PM, Jan-Christoph Borchardt
> <hey@jancborchardt.net> wrote:
>> We talked a lot about the relationship of unhosted and remotestorage
>> in the past, and at the Unhost unconference finally with more people
>> than just Michiel and me. We concluded that since we introduce 2
>> technical concepts to people which do not necessarily need to be
>> connected, we should separate them more clearly. While there is lots
>> of possible overlap and remotestorage was born out of the then
>> Unhosted project, we should have 2 strong separated brands also to
>> avoid confusion what is what.
>> 
>> »unhosted« means client-side web apps, written in Javascript, HTML,
>> CSS (check http://unhosted.org )
>> »remote storage« means per-user storages which use OAuth, CORS &
>> get-put-delete (adhering to
>> http://w3.org/community/unhosted/wiki/RemoteStorage )
>> 
>> That is, unhosted web apps can work without remotestorage. They can
>> just use localStorage, or they can use Dropbox, Google Drive, iCloud
>> or any other storage standard. Although remotestorage for now is the
>> recommended open standard because it is standardized, interoperable
>> and can be deployed by anyone.
>> And remotestorage can be used by more than just unhosted web apps. We
>> talked to people of Libre Office and Thunderbird before, and in
>> presentations have always said that the web apps do not necessarily
>> need to be client-side only. But unhosted web apps are recommended,
>> since they are platform-independent, portable and do not track you.
>> 
>> So let’s go! We have a new Github organization at
>> http://github.com/remotestorage – I already added some people involved
>> with remotestorage, and the remotestorage.js repository moved there
>> from unhosted.
>> Join our IRC channel #remotestorage on freenode.net and the mailing
>> list is kicked off with this post – join by mailing to
>> remotestorage@librelist.com, the archives will be available at
>> http://librelist.com/browser/remotestorage/
>> Also follow https://twitter.com/remotestorage_
>> 
>> 
>> Freedom from the web’s monopolies!
> 

Re: [unhosted] remotestorage separation from unhosted

From:
Martin Stadler
Date:
2012-09-12 @ 20:48
I'd say if the maintainer wants to be part of the yet-to-be-formed Remote 
Storage organization/team it would be great to have the code in a 
repository in the github organization. Else we just link. (Not being 
closely related to the project in this way of course doesn't mean not 
being part of the Remote Storage community.)


Am 12.09.2012 um 21:24 schrieb Jan-Christoph Borchardt:

> Do we fork them to the remotestorage Github organization? Or do we ask
> the authors if they want to transfer ownership to remotestorage, in
> which they can continue to develop them there? Or do we do nothing at
> all, just maybe linking to them?
> 
> I think asking the authors to transfer ownership is best (except
> ownCloud, which is not a dedicated remote storage only). Those which
> don’t want to do that we’ll still link, but it’s best to have it under
> one umbrella because it’s all about the same standard.

Re: Re: [unhosted] remotestorage separation from unhosted

From:
Martin Stadler
Date:
2012-09-12 @ 20:40
Am 12.09.2012 um 22:22 schrieb Mike Kazantsev:

> On Wed, 12 Sep 2012 21:24:10 +0200
> Jan-Christoph Borchardt <hey@jancborchardt.net> wrote:
> 
>> So what do we have?
>> 
> ...
>> 
>> remote storages:
> ...
>> https://github.com/mk-fg/django-unhosted (Python)
>> 
>> 
>> Do we fork them to the remotestorage Github organization? Or do we ask
>> the authors if they want to transfer ownership to remotestorage, in
>> which they can continue to develop them there? Or do we do nothing at
>> all, just maybe linking to them?
>> 
>> I think asking the authors to transfer ownership is best (except
>> ownCloud, which is not a dedicated remote storage only). Those which
>> don’t want to do that we’ll still link, but it’s best to have it under
>> one umbrella because it’s all about the same standard.
>> 
>> CC’d the authors – please let us know your stance on this.
>> 
> 
> From structural viewpoint I'm all for it, but not sure what that
> transfer means from a technical perspective.
> Probably a matter of reading the docs, but I thought I'll ask here
> anyway.
> 
> Do github allow to retain admin access to a repo within organisation
> without admin access to the rest of the repositories there?
> 
> How transfer itself should be performed?
> 
> Github won't let me transfer repo to an organisation unless I'm an
> admin there, but granting me an admin privileges seem to be a totally
> unnecessary overkill, if not a risk as well (if only because I might
> leak my access due to poor security practices).
> Though I guess such access will only be needed for a short time.
> 

Hi!

You can just push from your local git repository to the remote storage 
organization's on github. You can be granted commit rights for that 
without being an organization admin.

HTH,
Martin

Re: remotestorage separation from unhosted

From:
Martin Stadler
Date:
2012-09-12 @ 19:30
Feels great!

Glad to be part of the process.

Martin


P.S. Also cheers to a non-Google mailing list. :)


Am 12.09.2012 um 21:10 schrieb Jan-Christoph Borchardt:

> We talked a lot about the relationship of unhosted and remotestorage
> in the past, and at the Unhost unconference finally with more people
> than just Michiel and me. We concluded that since we introduce 2
> technical concepts to people which do not necessarily need to be
> connected, we should separate them more clearly. While there is lots
> of possible overlap and remotestorage was born out of the then
> Unhosted project, we should have 2 strong separated brands also to
> avoid confusion what is what.
> 
> »unhosted« means client-side web apps, written in Javascript, HTML,
> CSS (check http://unhosted.org )
> »remote storage« means per-user storages which use OAuth, CORS &
> get-put-delete (adhering to
> http://w3.org/community/unhosted/wiki/RemoteStorage )
> 
> That is, unhosted web apps can work without remotestorage. They can
> just use localStorage, or they can use Dropbox, Google Drive, iCloud
> or any other storage standard. Although remotestorage for now is the
> recommended open standard because it is standardized, interoperable
> and can be deployed by anyone.
> And remotestorage can be used by more than just unhosted web apps. We
> talked to people of Libre Office and Thunderbird before, and in
> presentations have always said that the web apps do not necessarily
> need to be client-side only. But unhosted web apps are recommended,
> since they are platform-independent, portable and do not track you.
> 
> So let’s go! We have a new Github organization at
> http://github.com/remotestorage – I already added some people involved
> with remotestorage, and the remotestorage.js repository moved there
> from unhosted.
> Join our IRC channel #remotestorage on freenode.net and the mailing
> list is kicked off with this post – join by mailing to
> remotestorage@librelist.com, the archives will be available at
> http://librelist.com/browser/remotestorage/
> Also follow https://twitter.com/remotestorage_
> 
> 
> Freedom from the web’s monopolies!
>