Hubzilla and Zot -- any insights for federated wiki?
coevolving opened this issue · 5 comments
Is there anything that the federated wiki community could learn from the Hubzilla as "a distributed network of hubs" at http://hubzilla.org/sandbox/index.html, and/or Zot, described as "a JSON-based web framework for implementing secure decentralised communications and services"?
Hubzilla seems to be a project that has evolved from Friendica, and is finding some alternative ways of getting around some roadblocks to Diaspora*. See the Hubzilla History at https://hubzilla.site/help/history .
Zot is part of Hubzilla at https://github.com/redmatrix/hubzilla/blob/master/include/zot.php , and there's an Intro to Zot at https://hubzilla.site/help/develop.
I've been experimenting with Hubzilla at https://hubzilla.site/channel/systems. I have some confusion about the way they do channels -- they can be (i) social, (ii) forum, (iii) feed, or (iv) special, as described at https://hubzilla.site/help/roles . This seems to be inexperience on my part, so I should think differently.
The project is intriguing to me.
Looking at an installation of Hubzilla, there's a strong recommendation for SSL (including what it means from the perspective of a user). From https://hubzilla.site/help/install ...
Before you begin: Choose a domain name or subdomain name for your server.
Hubzilla can only be installed into the root of a domain or sub-domain, and can not be installed using alternate TCP ports.
Decide if you will use SSL and obtain an SSL certificate before software installation. You SHOULD use SSL. If you use SSL, you MUST use a "browser-valid" certificate. You MUST NOT use self-signed certificates!
Please test your certificate prior to installation. A web tool for testing your certificate is available at "http://www.digicert.com/help/". When visiting your site for the first time, please use the SSL ("https://") URL if SSL is available. This will avoid problems later. The installation routine will not allow you to use a non browser-valid certificate.
This restriction is incorporated because public posts from you may contain references to images on your own hub. Other members viewing their stream on other hubs will get warnings if your certificate is not trusted by their web browser. This will confuse many people because this is a decentralised network and they will get the warning about your hub while viewing their own hub and may think their own hub has an issue. These warnings are very technical and scary to some folks, many of whom will not know how to proceed except to follow the browser advice. This is disruptive to the community. That said, we recognise the issues surrounding the current certificate infrastructure and agree there are many problems, but that doesn't change the requirement.
Free "browser-valid" certificates are available from providers such as StartSSLand LetsEncrypt.
If you do NOT use SSL, there may be a delay of up to a minute for the initial install script - while we check the SSL port to see if anything responds there. When communicating with new sites, Hubzilla always attempts connection on the SSL port first, before falling back to a less secure connection. If you do not use SSL, your webserver MUST NOT listen on port 443 at all.
Looks like good info. Thanks for the pointer.
Best regards -- Ward
On Jan 19, 2016, at 5:25 AM, David Ing notifications@github.com wrote:
Looking at an installation of Hubzilla, there's a strong recommendation for SSL (including what it means from the perspective of a user). From https://hubzilla.site/help/install ...
Before you begin: Choose a domain name or subdomain name for your server.
Hubzilla can only be installed into the root of a domain or sub-domain, and can not be installed using alternate TCP ports.
Decide if you will use SSL and obtain an SSL certificate before software installation. You SHOULD use SSL. If you use SSL, you MUST use a "browser-valid" certificate. You MUST NOT use self-signed certificates!
Please test your certificate prior to installation. A web tool for testing your certificate is available at "http://www.digicert.com/help/". When visiting your site for the first time, please use the SSL ("https://") URL if SSL is available. This will avoid problems later. The installation routine will not allow you to use a non browser-valid certificate.
This restriction is incorporated because public posts from you may contain references to images on your own hub. Other members viewing their stream on other hubs will get warnings if your certificate is not trusted by their web browser. This will confuse many people because this is a decentralised network and they will get the warning about your hub while viewing their own hub and may think their own hub has an issue. These warnings are very technical and scary to some folks, many of whom will not know how to proceed except to follow the browser advice. This is disruptive to the community. That said, we recognise the issues surrounding the current certificate infrastructure and agree there are many problems, but that doesn't change the requirement.
Free "browser-valid" certificates are available from providers such as StartSSLand LetsEncrypt.
If you do NOT use SSL, there may be a delay of up to a minute for the initial install script - while we check the SSL port to see if anything responds there. When communicating with new sites, Hubzilla always attempts connection on the SSL port first, before falling back to a less secure connection. If you do not use SSL, your webserver MUST NOT listen on port 443 at all.
—
Reply to this email directly or view it on GitHub.
Talking to myself before reading the actual issue, becaus it will generally reflect upon multi-federation federations:
Have been running into Hubzilla today via https://hub.transition-regensburg.de/.
Some tech and non-tech folks were also open to play with https://vector.allmende.io/#/room/#tnweb:matrix.allmende.io
There is active commitment in the German transition/transformation movement to utilise the strengths of shared infrastructure (See RFC 7476) for bridging weak ties to strong links (See Ned Rossiter's work).
As the previous link points to a Matrix room, we can conclude it was much easier to digest than a federated wiki I had started the first presentation with, knowing my local http://wortfabrik wouldn't be accessible to anyone.
Where I call federated wiki a passive federation, which only takes what is given, matrix federates actively between servers, like we did before.
How do we start dancing around each other, even as three?
Would https://github.com/WardCunningham/Smallest-Federated-Wiki/issues actually be a better place for this?
I'd then open one for the Matrix/Vector combo.
Yes, 4x as many watchers there. Let's move this conversation there. I'll close this issue.