Avoid centralization

[dbrgn]

Idea by @rorist:

An other thing that we can think about, is the centralization problem. The endpoints are decentralized, but the directory isn't. Maybe everyspace can host a version of the directory, but for the hackerspaces it should be as simple as possible to maintain and deploy (aka a static json). So I don't know what we can do about that, ideas?

[dns2utf8]

Maybe we should carry a log, so one would be able to apply our change?

[dbrgn]

What would that log contain?

[dbrgn]

Maybe everyspace can host a version of the directory, but for the hackerspaces it should be as simple as possible to maintain and deploy

The question in this case is addressing. In theory we could use multiple hosts with DNS round robin. The problem is that an "evil" or simply outdated directory would result in inconsistent data. If there are multiple directories on different URLs on the other hand, the directories can go out of sync.

We could also go fancy with DHT and the like, but I don't think there's much advantage in that :)

Maybe the directories could use another mechanism to sync themselves automatically?

[rorist]

I'll try Matrix.org a little bit today, but it's probably a little bit overkill :) The DNS approach could maybe be enough.

[dbrgn]

As Matrix is a messaging protocol, I don't think that's the right approach :)

Once the Maidsafe network is out of Alpha we could also publish there though.

[rorist]

Yeah I though we could hack it for our purpose, but it's indeed really chatroom oriented. Maidsafe look very good!

The problem we had with the directory was getting the data when it was down, if it's all published on git(hub) then this is fine, if the directory provider is down, somebody can easily take over and create a new domain.

There's not a huge need for syncronisation probably, a cron per hour may be just enough..

[rnestler]

We could also go fancy with DHT and the like, but I don't think there's much advantage in that :)

I think we should use blockchain here 😄

[dbrgn]

You meant "blockchain technology" 😛

[dbrgn]

There's not a huge need for syncronisation probably, a cron per hour may be just enough..

That's true.

[astro]

git is sort of a blockchain already. Why not maintain the directory in a git repository with one file per endpoint URL?

[dbrgn]

git is sort of a blockchain already.

Sorry, that was an inside joke, because marketing people love the term "blockchain technology".

Why not maintain the directory in a git repository with one file per endpoint URL?

You mean the actual directory endpoint data? Or just the URLs? I don't see added value in splitting up the URLs in multiple files. And the enpdoints should be managed by the spaces themselves, as many of them are dynamically generated.

[rnestler]

You mean the actual directory endpoint data? Or just the URLs? I don't see added value in splitting up the URLs in multiple files. And the enpdoints should be managed by the spaces themselves, as many of them are dynamically generated.

The directory is just a more or less static json file isn't it? Hosting and managing it directly on github would indeed ease maintenance and one could also easily sync it with just a git pull. Adding a new space to the directory would be as easy as opening a PR for the directory json file.

[dbrgn]

would

Note that this is already the way it's handled right now: https://github.com/fixme-lausanne/OpenSpaceDirectory

Maybe we could move the repo into this organization? What do you think, @rorist?