Hubzilla: Build a community of connected websites(hubzilla.org)
hubzilla.org
Hubzilla: Build a community of connected websites
http://hubzilla.org/
8 comments
Somehow this reminds me of the "webring" era of the internet, before search engines and social networking the best way to find more websites was to start from one you knew and look at the "ring" it belonged to.
The "community of websites" idea is perhaps misleading that way. Websites in this context are, pretty much, analogous to your Twitter or Facebook page.
I had a quick look but can't see what Hubzilla does different from Tent and Diaspora who also shipped their own open source software/protocol which was not compatible with anything else out there. I'd like to believe otherwise but for now it seems to me like just another bulet point on http://indiewebcamp.com/monoculture
Decentralised identity and access control. Internet single sign-on (cross domain authentication). Nomadic identity (true identity clones on multiple servers because hobbyist websites tend to kack it fairly frequently and everybody has to start over making friends with all their friends again).
Social networks which just pass messages back and forth and let you share/follow/whatever are doomed. Hubzilla may in fact be doomed but at least we aren't doing the same bloody thing as everybody else. Social networking is a very small part of what we do. You can take that away and we still have a viable project. Take social networking away from Diaspora and you've got bugger all.
Social networks which just pass messages back and forth and let you share/follow/whatever are doomed. Hubzilla may in fact be doomed but at least we aren't doing the same bloody thing as everybody else. Social networking is a very small part of what we do. You can take that away and we still have a viable project. Take social networking away from Diaspora and you've got bugger all.
Problem of course is that everything is kind of a mono culture at first. Tent.io at least had multiple projects working on implementations, but never seemed extremely active to me.
EDIT: that said, thank you for the indiewebcamp link, there are some very interesting things and ideas there! You might want to submit that to HN if it hasn't seen a big discussion already.
EDIT: that said, thank you for the indiewebcamp link, there are some very interesting things and ideas there! You might want to submit that to HN if it hasn't seen a big discussion already.
It was posted 3 and then 1 year(s) ago; no discussion so far.
It is compatible with Diaspora to some extent: https://redmatrix.me/help/diaspora_compat
Spending two years with IndieWeb convinced me that people generally are not interested in sustainable solutions as long as centralized services make it more convenient to post cat pictures. (Also see: Slack vs. IRC)
IndieWeb seems to still be active. Is it just a community of people making communities? Or what?
Anyway, the big fatal flaw in all this is that the technology isn't the only thing. You need adoption. You need a social network with at least a million people on it already. Then you can deploy it to various networks as open source.
You need something for social the way Wordpress is for blogs. Not totally peer to peer distributed. But something that an organization installs locally.
Hubzilla says all the right stuff but how many users do they have?
We have 300,000 at the moment. http://platform.qbix.com
Anyway, the big fatal flaw in all this is that the technology isn't the only thing. You need adoption. You need a social network with at least a million people on it already. Then you can deploy it to various networks as open source.
You need something for social the way Wordpress is for blogs. Not totally peer to peer distributed. But something that an organization installs locally.
Hubzilla says all the right stuff but how many users do they have?
We have 300,000 at the moment. http://platform.qbix.com
Just FYI,there are plugins for your wordpress installation to connect to the rest of the social indieweb community https://wordpress.org/plugins/indieweb/
You are probably right.
But perhaps this will change in the future for some kind of services.
Not probably right, absolutely right. And no, it won't change in the future. 99.99999% of regular people couldn't give a crap about underlying architecture or engineering.
Sustainability != engineering or architecture, it's about not losing your own data ( and memories with them ); so if more and more people are effected with DMCA takedows, 3 strike policies, they might become interested.
See http://justhugo.com/2015/10/16/freedom/ for example.
See http://justhugo.com/2015/10/16/freedom/ for example.
Non-technical people are going to be at more risk of total data loss if they try to store it themselves, sadly. This is a big part of why cloud services have taken off: they're outsourcing all the sysadmin for you.
Takedowns are never going to go beyond a fraction of a percent of the population.
Takedowns are never going to go beyond a fraction of a percent of the population.
It matters to you, me, other hacker news users, and the guy in the article with the "code is poetry" tattoo (shudder)... but not your average user. IMHO.
Regular people don't but organizations do.
Having control over your own open source installation means:
Not worrying about being charged
Being able to install the plugins you want
Being able to customize themes and appearance
Having sensitive info stay in-house
Not having to put up with a one-size-fits-all policy for eg comments or real names
Having control over your own open source installation means:
Not worrying about being charged
Being able to install the plugins you want
Being able to customize themes and appearance
Having sensitive info stay in-house
Not having to put up with a one-size-fits-all policy for eg comments or real names
Formerly known as RedMatrix.
The lead developer is the creator of Friendica, which is still kicking: http://friendica.com/
https://en.wikipedia.org/wiki/Friendica
The lead developer is the creator of Friendica, which is still kicking: http://friendica.com/
https://en.wikipedia.org/wiki/Friendica
"Friendica is what Diaspora should have been."
Federated social networks are technically interesting, but somebody has to figure out some way to get a user base. It's encouraging to see that Frendica has a few more sites than it did six months ago.[1] But 28 sites isn't many. Especially since many of them seem to be down.
I registered for Friendica.eu, which appears to be one of the larger servers. There are a total of 80 people and groups. Response time for any request is 5-10 seconds. (Behind the scenes, it's PHP.) There's an IRC server, but nobody is on the #friendica channel. Overall, it feels like using a BBS system from the 1980s.
There's already spam. "Natrol Fat Intercept Tablets, Green Coffee Bean with Raspberry Ketones…" "Galaxy Phone..."
I'd like to see someone replace Facebook with a federated system, but it doesn't look like Friendica can do it.
[1] http://dir.friendica.com/siteinfo
Federated social networks are technically interesting, but somebody has to figure out some way to get a user base. It's encouraging to see that Frendica has a few more sites than it did six months ago.[1] But 28 sites isn't many. Especially since many of them seem to be down.
I registered for Friendica.eu, which appears to be one of the larger servers. There are a total of 80 people and groups. Response time for any request is 5-10 seconds. (Behind the scenes, it's PHP.) There's an IRC server, but nobody is on the #friendica channel. Overall, it feels like using a BBS system from the 1980s.
There's already spam. "Natrol Fat Intercept Tablets, Green Coffee Bean with Raspberry Ketones…" "Galaxy Phone..."
I'd like to see someone replace Facebook with a federated system, but it doesn't look like Friendica can do it.
[1] http://dir.friendica.com/siteinfo
I think you've hit the nail on the head with the spam comment.
In a federated system, it is up to everyone to protect themselves against spam.
We put up with it for email, because in the most part it pre-dated other solutions. I don't think people will put up with it for social networking.
In a federated system, it is up to everyone to protect themselves against spam.
We put up with it for email, because in the most part it pre-dated other solutions. I don't think people will put up with it for social networking.
Closed social networks have plenty of spam. I'd say the main difference is that on email, you get messages from everyone, whereas in most social networks, you need to voluntarily subscribe to someone's feed to get their messages; that alone massively cuts down on the efficiency of spam.
All social networks need an "introduction" system of some sort so people can find you, and some of those introductions will be spam. For example, on twitter there are fake accounts that will follow you in the hope of getting you to look at their spam profile.
I see tons of spam on Facebook from 'friends'.
I was amazed that anyone was bothering to spam Frendicia. The audience is so tiny.
> There's an IRC server, but nobody is on the #friendica channel.
I see 17 people now on the channel @ Freenode. Maybe you were using some other IRC server?
I see 17 people now on the channel @ Freenode. Maybe you were using some other IRC server?
For-profit social networks have a central actor with funds to advertise the network and do the tedious labour of managing spam and abuse. Without a central actor you're limited to very slow organic growth and persuading people to volunteer to clean up.
Hm, this kind of things always seems to tackle the problem in the wrong way. Instead of aiming for decentralized, why is no one building a completely distributed solution instead?
The only work being done I can think of, that is still active is IPFS today, that at least is trying to build a distributed technology, that services like this could be build on top of.
The only work being done I can think of, that is still active is IPFS today, that at least is trying to build a distributed technology, that services like this could be build on top of.
Indieweb does, see http://indiewebcamp.com/webmention
"Completely distributed" is much harder to kickstart and gain critical mass. Instead, if a few dedicated parties do all the work to set up and maintain a few servers that the general public can start using right away with no time investment, it is easier than more people will use the system.
There's Freenet, which already has multiple messaging systems.
Damn that name! Now I have to rename my software for automatically translating GitHub pull requests into Bugzilla bugs ;)
As a disclaimer, I'm working on a competing(ish) protocol called Muse.[1]
Unfortunately the documentation for the federated social projects I'm aware of is always severely lacking (believe me, my own included). It makes some key points very difficult to understand. With that caveat aside, this is what I think I understand about the general system architecture of Diaspora, Hubzilla, and Tent:
* Everyone runs their own server. Data on the server is plaintext at rest, but encrypted in transit.
* The protocol (only text-based?) governs communications between servers. It describes the kind of things you would expect social websites to need to do: make comments, have profiles, etc. Examples of protocol outputs: Tent[2], Hubzilla[3], Diaspora[4]
* Internally, the servers deal with privacy, sharing, etc. Your personal server and their code together determine what data is acquired, stored, shared, etc.
If this mischaracterizes any of the above protocols, I would be really grateful for corrections. It's to everyone's benefit to understand the high-level technical details of these projects. However, the system architecture described above is not, in my mind, a tenable approach to distributable social applications. Simply put, this kind of "private server as my digital avatar" + "protocol so avatars can talk" paradigm completely misses the appropriate choice of abstractions and division of concerns for social applications.
First and foremost, this is still yet another example of "privacy by promise". It just so happens that the promise is given to you by the servers of whomever you're sharing with. But then, as data is decrypted at rest, you must also trust their coding ability, their deployment ability, their... this gets very messy, very quickly. The security footprint for implementing these protocols is immense.
Secondly, this approach focuses on one specific use case: websites. The vast majority of publicly-networked applications will, at some point, have a need to perform identity, sharing, or content management. However, they may not necessarily have anything to do with text: for example, a distributed sensor network might communicate only using binary messages, but that doesn't make it any less social. Since bytes are the more basic unit, any general-purpose social protocol should therefore support them natively.
A much more robust approach is to address the "social protocol" at a much lower level: to provide only the bare minimum that any social application will need, giving transport-layer bytestreams cryptographically-enforced privacy with many-to-many capability. Only then can you escape requiring everyone to operate their own web service, which is, I firmly believe, an unrealistic goal.
[1] https://github.com/Muterra/doc-muse
[2] https://raw.githubusercontent.com/tent/tent.io/master/source...
[3] https://github.com/bartekrutkowski/hubzilla/blob/master/exam...
[4] https://wiki.diasporafoundation.org/Federation_protocol_over...
Unfortunately the documentation for the federated social projects I'm aware of is always severely lacking (believe me, my own included). It makes some key points very difficult to understand. With that caveat aside, this is what I think I understand about the general system architecture of Diaspora, Hubzilla, and Tent:
* Everyone runs their own server. Data on the server is plaintext at rest, but encrypted in transit.
* The protocol (only text-based?) governs communications between servers. It describes the kind of things you would expect social websites to need to do: make comments, have profiles, etc. Examples of protocol outputs: Tent[2], Hubzilla[3], Diaspora[4]
* Internally, the servers deal with privacy, sharing, etc. Your personal server and their code together determine what data is acquired, stored, shared, etc.
If this mischaracterizes any of the above protocols, I would be really grateful for corrections. It's to everyone's benefit to understand the high-level technical details of these projects. However, the system architecture described above is not, in my mind, a tenable approach to distributable social applications. Simply put, this kind of "private server as my digital avatar" + "protocol so avatars can talk" paradigm completely misses the appropriate choice of abstractions and division of concerns for social applications.
First and foremost, this is still yet another example of "privacy by promise". It just so happens that the promise is given to you by the servers of whomever you're sharing with. But then, as data is decrypted at rest, you must also trust their coding ability, their deployment ability, their... this gets very messy, very quickly. The security footprint for implementing these protocols is immense.
Secondly, this approach focuses on one specific use case: websites. The vast majority of publicly-networked applications will, at some point, have a need to perform identity, sharing, or content management. However, they may not necessarily have anything to do with text: for example, a distributed sensor network might communicate only using binary messages, but that doesn't make it any less social. Since bytes are the more basic unit, any general-purpose social protocol should therefore support them natively.
A much more robust approach is to address the "social protocol" at a much lower level: to provide only the bare minimum that any social application will need, giving transport-layer bytestreams cryptographically-enforced privacy with many-to-many capability. Only then can you escape requiring everyone to operate their own web service, which is, I firmly believe, an unrealistic goal.
[1] https://github.com/Muterra/doc-muse
[2] https://raw.githubusercontent.com/tent/tent.io/master/source...
[3] https://github.com/bartekrutkowski/hubzilla/blob/master/exam...
[4] https://wiki.diasporafoundation.org/Federation_protocol_over...
Author(s) would really gain some credibility by adding information about their identity inside the hubzilla website.
I first wondered whether this was a mozilla project, then looked for a name, thing is visible. Why should I trust them then...
I first wondered whether this was a mozilla project, then looked for a name, thing is visible. Why should I trust them then...