Friendica and Red

I get asked this a lot - "What is the difference between Friendica and Red?" Is Friendica "going away"?

Not at all. Red is providing us an opportunity to develop some novel concepts in decentralised communications which haven't been tried before.

Ultimately Red is being created for a different audience than those who might gravitate towards Friendica. Friendica is a great personal communications service - and the fact that we can federate with many other services makes this a highly desirable platform.

Red embodies an entirely new architecture, but it is primarily being built for service providers who wish to scale to much higher levels and perhaps create a self-sufficient business out of social communications. Serivce federation isn't as important since this reduces scalability.

Many of the new concepts in Red will be backported to Friendica - in fact several of them already have.

 

If you go to McDonalds you may find that they offer more than one type of sandwich and you can choose which is best for you. That is precisely why we have a choice between Friendica and Red. You can choose which is best for you. When Red is fully functional a few months from now, many people will stick with Friendica. We applaud and support that decision. Red is not nearly as capable in terms of service federation, but it has some very unique capabilities which will appeal to some people. Ultimately both platforms will be able to interact.

So don't think of Red like it's a new kind of cheeseburger to destroy all other cheeseburgers. Think of it as whether or not you want mayonnaise and/or pickles on your cheeseburger, or if you wish to stick with garlic sauce and Jack cheese.  Ultimately it's your decision. Both taste good - but you might prefer one over the other.   

 

 

Red

by  Commander Zot

I've been working on Red for three months (off and on, there are lots of demands on my time). Here is an update.

Most of us think of "online networking" and think only in terms of "social networking" because of all the influence that Facebook has had in that realm. It has become apparent that the abuse of privacy has only one solution - take the private information out of the hands of outsiders and keep it under the control of those who are communicating. This means that a future which involves "privacy" belongs to decentralised communications, not to centralised data silos. We knew that already and was the basis for Friendica.

But also we've come to accept that the "social" part of networking is the only thing that matters. That everything on the modern web is all about friends.

It's not.

Red is an attempt to look at all of this from a higher level and see where we've been and where we're going. The whole "social" bit came about because email couldn't protect us from spam. So we started only accepting messages from "friends". And so now we have these huge corporations which are geared around the concept of communicating with friends.

Facebook is merely a communications system with web accessible resources, all focused on the concept of "friends". There is also inherent censorship and blockage of people with non-mainstream beliefs.  Filtering is performed which uses Facebook algorithms to decide which content by which friends you can see at any one time. What you see in your stream isn't under your control.

Now let's look at Red. Red is simply a network. It has attached web resources. It is decentralised. It isn't concerned with the "social" bit, because "social" just means a granting of permissions to do stuff. Red has a permissions system which can emulate "social networking", and much more.

But Red isn't about people. It's about thought streams.  We call them "channels". You can create any number of channels, and some of these can represent people - like you for instance. And they can interact just like in a social network. But channels can represent any thought stream, hobby, interest, person,  discussion topic, anything. They can be about your music. They can be scientific discussions on a particular topic or range of topics. They can be a personal blog or a marketing site for a new product. You can attach web resources to channels such as  photo albums and event listings and static web pages. And you can create rules on how other channels or collections of channels can interact with each of them - or not. 

So each channel is essentially a content management system attached to a communications system and a set of rules about what interactions are allowed - and what content is visible to any or all other channels. And since it is decentralised, private information is only shared with the hubs of other channels that are involved.

Important: There isn't any central repository anywhere which has access to *all* private information.

You also have an analogue dial representing the "affinity" between this channel and any other specific channel. If you're "channel surfing" you can look at specific other channels, or mixtures of other channels, or those with a specific range of affinity. And if those channels permit you to do so, you can interact with them. You can also interact with specific subsets of channels. In a social network context you might call this a "private group".

And you can change channels. They are all separate entities, so things can't leak between your channels. So not only does each channel have privacy controls for the other channels it interacts with, different channels can interact with completely different sets of permissions.

In Friendica for instance you can create private profiles and photos that can only be seen by co-workers, and another which can only be seen by potential girlfriends. In Red, you can do exactly the same. But you can also interact with co-workers on a completely different channel and share work related stuff without having to worry about what permissions you might need to set on each thing you post or share. One is a different thought stream entirely from the other.   

The other big thing we're doing in Red is taking the internet domain name system out of the equation. You need this to visit web resources, but you don't need it for basic communications. You can move around and interact from other places. So if your channel doesn't require web resources, you can communicate from anywhere. We hope to build desktop and mobile communication clients which can operate independently of the content management web servers, and allow you to stay in communication even if those go down - (which happens). 

So in summary, Red isn't a social network in any classical sense, though it contains all the same components as a classical social network and has better privacy controls. So one could use it in that manner.

Red is a matrix of interacting thought streams.

Want to connect to the grid? We're still several months away from a solid prototype. This is a lot more complicated than a decentralised social network and it's taking some time to develop because nobody has ever done anything quite like this before.

Stay tuned.

Difference between Diaspora and Hubzilla

Original post https://framasphere.org/posts/1003816

Diaspora has one goal → Diaspora. Everybody within Diaspora is keenly aware that they are a part of Diaspora. The goal is to be a part of Diaspora and aligned with whatever the Diaspora community is aligned with. There are other interests represented in Diaspora, but they (#hashtags) only exist to filter content. There are no smaller “communities” per se. It is designed as a large melting pot. Communities are expected to find themselves within the large melting pot and organise themselves. But there are no community tools – like forums, events, file repositories, that kind of thing. So communities can’t organise if they wanted to. All they have is hashtags.

Hubzilla has one goal → to connect communities. These could be dating communities or shopping communities or social network communities or small business websites used by small businesses. In these cases people will be a part of whatever community they are already a part of, but at the same time they will become members of a larger community. As you know, some of these people are Diaspora members and aren’t even aware that they are part of a community that is larger than Diaspora (“the federation”). In their mind – they just think they are part of Diaspora, or part of a dating website or shopping forum. But they can communicate (socially) with people from other communities. The purpose of hubzilla is to connect communities and their resources and assets together both socially and most important – with privacy. So sure, some people will use it as a large social network just like Diaspora. But growth and stability doesn’t come from building a giant social network – it comes from building on existing communities and linking them together.

There are hundreds of thousands of special interest websites and forums on the web where people discuss things and have already built communities. Drupal, phpforum, wordpress, all bring people together into communities. But what these other software packages don’t do is connect the communities. This is where the next web explosion will come from. Currently if you want to connect communities, you need to do it through facebook or twitter. Hubzilla allows you to connect communities on your own privacy terms. We let you adapt the software to the way your community works instead of doing like Diaspora does and mold everybody into a single interface which only sends posts back and forth and chooses who to share with. That’s really all it does. Most existing web communities have rich forums, file repositories, photo albums, calendaring, web pages and libraries, chat rooms – all kinds of community resources and they adapt different software to provide these. Many have different rules and policies and it can be tricky to connect communities with different rules. You need flexible permissions. We have that. The permissions work no matter where you are and what community you’re in and what website you’re using.

So yes, hubzilla could turn into a large “social network”, but it is one that is build from the bottom up rather than from the top down. By developing from the bottom up, we ensure that both the individual and the community have control as it grows. When you build from the top down, it forces people into a rigid and limited world view that is decided by the project leaders and leads to a homogeneous community. This is how we differ from the hordes of projects trying to be a “social network” and take on Facebook. Our project respects diverse communities and gives them the tools to maintain their identity and privacy when and as they connect to the larger network and link to other communities and people.

Mobility between sites

Friendica just received a nice new feature - the ability to take your account elsewhere (e.g. to another server) and keep all your friends. You've always been able to export your content, but until now we haven't had a good import tool. It's a hard problem. We still have some issues with importing the old posts and content, but keeping one's friends is the most important thing that people said they wanted when they re-located to other servers.

There are some limitations - and this won't federate easily to your Diaspora and StatusNet friends - as the underlying communications protocols currently have no corresponding "move existing friend" mechanisms. But assuming both sites have the same set of connectors available, all your other friends should come across fine - including those on Facebook, Twitter, blogs, and email (besides those on Friendica). 

Note that we are building Red (our next generation communications network) from the ground up with location mobility.

A big thanks to Fabio Comuni for bringing this to Friendica. The most wonderful part of community developed open source software is that anybody can make a difference, and it only takes a few talented people to bring back online freedom and privacy to a world where it has been mostly lost.

How to install Hubzilla on Dreamhost

You can have the documentation on how to install Hubzilla on every hub. Example https://hubzilla.site/help/install You can just type /help/install

Here is a step by step tutorial how to install a hubzilla for your group, family or simply for yourself on Dreamhost. Dreamhost allow it even on the share hosting. If you don’t have an account on Dreamhost you can have $50 off if you click here

 

You can install hubzilla on a domaine or subdomaine. For this example let’s install on hub.supername.com You should create the subdomaine  and a database (note the name, the hostname of the database and the password)

 

How to install hubzilla with SSH

If you know ssh and linux command line, this solution is the best for you.

ssh user@serveur

type the ssh password

#go to the directory who has the same name as your subdomaine

cd hub.supername.com

#net step git don’t forget the point .

git clone https://github.com/redmatrix/hubzilla.git .

mkdir -p “store/[data]/smarty3”

chmod -R 777 store

util/add_addon_repo https://github.com/redmatrix/hubzilla-addons.git hzaddons

 

The hardest part is done

Then go with a browser at the url of your site

First screen is to check if all prerequisit is ok on Dreamhost all is fine

Second screen : enter your mysql host, mysql user, password of the user and name of the database

third screen : email of the admin and the time zone

 

congratulation you installed your hubzilla successfuly

 

the last part is to create a cron task. With Dreamhost it is easy. go to your admin panel at dreamhost. Menu Goodies > cronjob

put

cd /home/username/hubzillasubdomain; /usr/local/php54/bin/php include/poller.php

on the cron job

Your server is ready. Use your administration email first. With this account you will be allowed to administrate your hubzilla

 

 

 

 

 

 

How to install Diaspora on Debian

Installing Diaspora / postgress

Just type this command

apt-get install diaspora-installer

Installing Diaspora / mysql

apt-get install diaspora-installer-mysql

 

Have fun

How to install Hubzilla on Dreamhost

You can have the documentation on how to install Hubzilla on every hub. Example https://hubzilla.site/help/install You can just type /help/install

Here is a step by step tutorial how to install a hubzilla for your group, family or simply for yourself on Dreamhost. Dreamhost allow it even on the share hosting. If you don’t have an account on Dreamhost you can have $50 off if you click here

 

You can install hubzilla on a domaine or subdomaine. For this example let’s install on hub.supername.com You should create the subdomaine  and a database (note the name, the hostname of the database and the password)

 

How to install hubzilla with SSH

If you know ssh and linux command line, this solution is the best for you.

ssh user@serveur

type the ssh password

#go to the directory who has the same name as your subdomaine

cd hub.supername.com

#net step git don’t forget the point .

git clone https://github.com/redmatrix/hubzilla.git .

mkdir -p “store/[data]/smarty3”

chmod -R 777 store

util/add_addon_repo https://github.com/redmatrix/hubzilla-addons.git hzaddons

 

The hardest part is done

Then go with a browser at the url of your site

First screen is to check if all prerequisit is ok on Dreamhost all is fine

Second screen : enter your mysql host, mysql user, password of the user and name of the database

third screen : email of the admin and the time zone

 

congratulation you installed your hubzilla successfuly

 

the last part is to create a cron task. With Dreamhost it is easy. go to your admin panel at dreamhost. Menu Goodies > cronjob

put

cd /home/username/hubzillasubdomain; /usr/local/php54/bin/php include/poller.php

on the cron job

Your server is ready. Use your administration email first. With this account you will be allowed to administrate your hubzilla

 

 

 

 

 

 

Hubzilla on wikipedia

As it is apparently hard to create a new page on wikipedia, here is the draft version of hubzilla page. A draft could be deleted and as this page is not bad and could be copy just in case.

https://en.wikipedia.org/wiki/Draft:Hubzilla

Hubzilla (formerly known as Redmatrix) is a community management platform that is designed to mesh with other instances running the same software. It is considered a platform for federated networking, and is compatible with both Diaspora and Friendica. Hubzilla is notable for combining aspects of social networking, blogging, forums, cloud storage and content management all into one application.

Hubzilla
Original author(s) Mike Macgirvin
Developer(s) Hubzilla community
Stable release 1.3. / March 2016
Written in PHP
Operating system Cross-platform
Platform Apache, Nginx
Type community management platform
License MIT License
Website [1]

 

Development History

In 2012, Mike Macgirvin of the Friendica project stepped down[1], and formed an experimental communication platform named Friendica Red. This system existed for exploratory purposes, and was designed based on lessons learned from developing Friendica.

Much of the design concepts for the new platform would be based on ideas about user identity management and privacy permissions. It leverages a unique federation protocol named Zot, which acts as the design successor to Friendica’s DFRN protocol.

As time went on, Friendica Red was rebranded RedMatrix, before the name Hubzilla was decided on. On December 24th, 2015, Hubzilla 1.0 was officially launched[2].

Features

Hubzilla can be defined as a decentralized communication and publishing platform. Any server running Hubzilla is defined as a hub, which can function independently of any other hub in the network.

Channels

Channels are a core concept for the platform – in short, each channel is an activity stream of objects that can represent a specific action, such as a posting a status or uploading a photo. This stream can show both public and private activities, and an ACL permissions system determines which users can access a given entry. Each channel also contains a unique Webfinger address, for example https://example.com/channel/bob would be represented as bob@example.com

A Channel can be created for the following use-cases:

  • A Social Stream
  • Blogging
  • Branded Product Streams
  • Group Forums

A user is assigned their first channel upon registration, but they can create as many different channels as their hub allows. Each channel in turn can connect to another channel as a contact. This mechanism will allow a user to interact with posts, as well as post on the wall of other channels as themselves. Private messages and statuses can also be passed back-and-forth from one connected channel to another.

MagicAuth

MagicAuth is a type of in-browser encryption that grants access permissions on remote hubs. In a sense, it is a workaround to a long-standing problem in federated social networks: ordinarily, users couldn’t visit each other’s profiles and directly interact with them if both people are connected through different servers. MagicAuth exists as a means of granting access permissions to visiting users. The use-case works like so:

  1. Bob’s channel is on https://example.com/channel/bob, with the channel address of bob@example.com
  2. Bob visits Alice’s channel at https://othersite.com/channel/alice, ie, alice@othersite.com
  3. When Bob visits, his browser session performs a cryptographic handshake with Alice’s channel
  4. Bob is allowed to comment and like posts on Alice’s channel while he is visiting.
  5. Bob will also see private posts meant for him when visiting.
  6. If Alice allows people to make posts on her wall, Bob will be able to do that as well.

Cloud Storage

By default, each channel is given DAV access for file storage. This storage includes uploaded photo albums, and can allow for videos and other documents. Cloud storage can be accessed through a DAV client, and in some instances be integrated into the desktop file manager itself.

Web Pages

Channels are allowed to create web pages based on a templating system.

Directories

Themes and Layouts

Plugins

OpenID

Hubzilla can also function as an OpenID provider, allowing users to log into OpenID-enabled sites with their Hubzilla channels.

See also

References

 

 

  1. Macgirvin, Mike. “Hubzilla (1.0) release”.

External links

The first web site

Do you know the first web site of the world.  It was http://info.cern.ch In Switzerland

Even today you can browse it as it was in 1991.

 

 

Hubzilla 1.3 released

hubzillaWe are please to announce the immediate availability of Hubzilla Community Server V1.3, our web software for building and linking decentralised community websites. The current release is building on our momentum to provide a much more configurable and adaptable platform for creating and linking website communities of all sizes and descriptions while providing autonomous privacy controls for all web resources.

The highlights are
1) ability to attach metadata to more stored resources which allows new types of plugins/addons to be created,
2) radically simplified setup and operation provided by the “Hubzilla UNO” configuration, and
3) continued work on the web interface to provide a pleasant and smooth flowing experience.

Please find out more about the project at http://hubzilla.org or visit our project page at https://github.com/redmatrix/hubzilla .

Summary of changes in this release:

Admin Security configuration page created which consolidates several previously hidden settings:
Communication white/black lists
Channel white/black lists
OEmbed white/black lists
Admin Profile Fields page created which manages the availability and order of standard profile fields and allows new fields to be created/managed
Allow guest/visitor access to view personal calendar
“Poke” module reworked – page UI updated and “poke basic” setting introduced which limits the available poke “verbs”.
“Mood” module UI reworked
“profile_photo” module UI reworked
“cover_photo” module UI reworked
“new_channel” module UI reworked
“register” module UI reworked
“pubsites” module UI reworked
item-meta (“iconfig”) created which implements arbitrary storage for item metadata for plugins
abook-meta (“abconfig”) created which implements arbitrary storage for connection metadata for plugins
“Strict transport security header” made optional as it conflicts with some existing Apache/nginx configurations
“Hubzilla UNO” (Hubzilla with radically simplified and locked site settings) implemented as an install configuration.
.well-known directory conflict worked out to support LetsEncrypt cert ownership checks without disrupting webfinger and other internal uses of .well-known
Lots of work on ‘zcards’ which are self-contained HTML representations of a channel including cover photos, profile photos, and some text information
Long standing bug uncovered which failed to properly restrict the lower time limit for public feed requests
A number of fixes to “readmore” to fix page jumping
Bugfix: persons other than the channel owner who have permission to upload photos to a channel could not do so if the js_upload plugin/addon was enabled
Siteinfo incorrectly identifying secondary directory servers
Allow admin to set and lock features when UNO is configured
Atom feeds: alter how events are formatted to be compatible with GNU-social
Moved several more classes to “composer format” and provided an autoloader.
Bugfix: require existing password to change password
Bugfix: allow relative_date() to be translated to Polish which has more than two plural forms.
Plugin API: add “requires” keyword to module header to indicate dependent addons
ActivityStreams improvements and cleanup: photo and file activities
UI cleanup for editing profile when multiple profiles enabled
Removed the “markdown” feature as there are numerous issues and no maintainer.
Provide “footer” bbcode to ease theming of post footer content
Bugfix: install issues caused by composer code refactor and typo in postgres load file

Plugins:
keepout – “block public on steroids”
pubsubhubbub – provides PuSH support to Atom feeds, required for GNU-social federation
GNUsocial protocol – under development
Diaspora protocol – some work to ease migration to the new signing format
Diaspost – disabled; numerous issues and no maintainer
smileybutton – theme work and fixed compatibility with other jot-tools plugins

 

more information

Hubzilla uno

Mike Macgirvin make this information

Hubzilla UNO is a configuration of Hubzilla specifically designed to appeal to a broad
community. All configurations and options and site features which have traditionally
caused confusion amongst those who are unfamiliar with and alienated by Hubzila’s advanced
technical concepts have been removed. The result is a software base which is drastically
simplified and approachable by a much larger audience, with a corresponding loss of
(significant) functionality.

This is accomplished by taking a normal hubzilla server and disabling all the advanced features.
Not tucked away as hidden options as per the current design, but in fact the advanced features
are completely disabled and unavailable.

A server can choose to be a Hubzilla UNO server at installation time. This is a permanent and
potentially irreversible decision. One can migrate their UNO channel to a “normal” hubzilla server,
but they *cannot* clone it (in either direction). This also means that hubzilla UNO can achieve a
high degree of compatibility and federation with other primitive communication services; which is
impossible for a hubzilla server that supports clones. Hubzilla UNO is also 100% compatible with
Hubzilla and “federates” without any limitations. This provides a compatibility bridge to traditional
services and networks for those willing to give up Hubzilla’s nomadic identity feature.

The most difficult decision is providing support for forums. Since forums require understanding
of the concept of “multiple channels per account” and this has traditionally caused confusion, it
was decided that forums would not be supported on hubzilla UNO. Members may interact with forums
that are provided on traditional hubzilla servers.

no nomadic clones
no permission options (ACL only).
no DAV (file uploads are still available through the web interface)
no multi-channels
no multi-profiles
no webpages
no bookmarks
no forums
no apps
no built-in “webchat”
no channel sources

limited features, all of which will have been preset

Development tasks:

Most of this work is reasonably straight-foward and merely involves appropriate “#ifdef” code blocks.
The largest development task is to bring back support for the older Friendica style account migration
since cloning will not be an option. This means if your hub shuts down, we will attempt to re-establish
your connections from a new service; but you cannot “just carry on” during brief outages.

—–

Probably some rough edges but this is mostly done. Import of UNO channels into a traditional hubzilla server is blocked until the migration bit is worked out. It’s basically taking Hubzilla and stripping it down. Even stripped of a large number of advanced features it still has orders of magnitude more functionality than Diaspora (for instance) as far as conversational community software goes, so this configuration may appeal to a number of people.

Hubzilla 1.2 Community Server released.

http://hubzilla.org
https://github.com/redmatrix/hubzilla

CHANGES from 1.1:

Provide extra HTTP security headers (several of them).
Allow a site to disable delivery reports if disk space is limited
Regression: Wrong theme when viewing single post as non-member
Some Diaspora profile photos use relative URLs – force absolute
Add locked features to siteinfo report to aid remote debugging
Provide version compatibility checking to plugins (minversion, maxversion, and minphpversion)
Account config storage
Provide optional integrated registration and channel create form
cli utility for managing addons
issue with sharing photo “items”
cover photo manager: upload, crop, and store
cover photo widget created
rework the connections list page and provide a few management features there
fixed issue with Comanche layout definitions loaded by plugins
provide ability to separate delivery functions from item_store() and item_store_update() – some forum messages were being redelivered when cloned.
call build_sync_packet() on pdledit changes
Abstract the project name and version so these can be customised or removed
Allow hiding the ratings links on a per-site basis
db_type not present in international setup templates – was unable to choose postgres.
item_photo_menu logically divided into a) actions on the post, b) actions related to the author
bug: default channel not reset to 0 when last channel removed
create widget containing only the contact block
regression: public forums granted send stream permissions to connections
workaround Firefox’s refusal to honour disabling autocomplete of passwords
regression: photo’s uploaded to a channel by a guest (with file write permissions) not saved correctly.
provide mechanisms for custom .well-known handlers (needed for LetsEncrypt ownership verification)
proc_run modified to use exec() instead of proc_open() – causing issues on some PHP installations
remote delegation failure under a specific set of circumstances which we were finally able to duplicate
Delegation section of Channel Manager was missing names and contained useless notification icons.
Change “expire” channel setting to show system limit if there is one.
Regression: provide a one-click ignore of pending connection
Config to control directory keyword generation on client and server.
“Collections” renamed to “Privacy Groups”, documentation improved
widget_item – allow use of page title instead of message id
Add site black/white list checking to all .well-known services
reduce incidents of screen jumping when “showmore” is activated
add oembed provider for photos

Addons:

CSS theming of pageheader plugin
xmpp addon ported from Friendica
Diaspora private mail issues after the third reply
Occasional issue with Diaspora connection requests
Add notification email to Diaspora PMs
Allow anonymising platform and version for statistics
msgfooter addon created
removed embedly plugin
sync clones after superblock addition
“keepout” plugin created

source

how to update friendica with ssh

here is a new version on how to update your friendica
we assume you have acces with ssh to your serveur

With filezila rename your directory where you have your friendica to friendiold
make a new directory name it friendi but you can choose the name you want
run the commands bellow you can copy past it

cd friendi
git clone https://github.com/friendica/friendica .
git clone https://github.com/friendica/friendica-addons.git addon

copy the old .htconfig.php from the old directory to the new one. It is done

Friendica 3.4.3-2 has been released

There were recently changes in the Dias­pora* pro­to­col which dis­turbed the fed­er­ated com­mu­ni­ca­tion between the projects. To com­pen­sate the changes Frien­dica 3.4.32 has been released

How to Update?

If you have an instal­la­tion using the git repos­i­tory directly, all you have to do is a git pull in the frien­dica direc­tory. That will fetch the new ver­sion from the mas­ter branch and you are ready to go. The devel­op­ment branch of Frien­dica 3.5 Aspara­gus, has been updated as well.

Alter­na­tively you can find a zip file of the released ver­sion of frien­dica at github​.com for down­load. Just unzip it on your local machine and replace the files on your server with the new files.

Why the number of hubzilla channels is growing so slowly ?

You have 2 sites that show the growing of hubzilla 1 . http://hubchart.hubzilla.it/ and the-federation.info. Here is the graphic of hubchart who show that less than 900 channels are active on hubzilla. This is not growing anymore but very stable. The other site the.federation.info is more the federation. it shows hub/pod for diaspora, friendica and hubzilla.

20160123

 

Hubzilla is a fantastic tool for community communication. It has lot of features and we can do lot of things. But there is no massive adoption. After the publication of version 1, some blog posts was publish and few testers subscribe. But something is missing.

 

Why it is so difficult to attract users ? That is a real question. I don’t have easy answer but just hypotheses. If you have other hypotheses I would be happy to know your ideas. How to attracts users ?

 

Here is some of my ideas but only few explications. Maybe we could work on these directions.

  • First Hubzilla is not known. People don’t know it. We must write articles about hubzilla and make it known.
  • Hubzilla is complicated. Exept few developpers and early adopters who are experts and love it, most people don’t understand fully what is hubzilla. For them it is a kind of social network like diaspora. They don’t understand what is the nomadic identity and what is the advantage of hubzilla. Furthermore if we use it, you can find so many parameters and settings, too many. You can easily get lost in the settings.
  • Ergonomy is better but should be improved. People don’t have to read documentation to use it. If you ask a question and someone reply : read the documentation, you got the wrong answer. Documentation is important but should not be mandatory for basic users.
  • Virality. That is the main point. If a user is happy he should talk to everybody. Hey come with me and use this wonderfull software !!!! What is missing to improve the virality of Hubzilla ?
  • Fidelity. You try and you stay, you test and you adopt. Personaly at the begining I force myself to try hubzilla. I felt lost. But after a period, now I am kind of addicted. But the effort to get addicted was hight. User should feel well after the first try and return. If we improve simplicity and ergonomy it would be easier for adoption.
  • Network effect and invitation process. You can use hubzilla like a blog but most of people use it like a discussion platform, like a forum or social network. If you find people with the same interest it is easier. If your blog get comment it encourage you and write more posts. If you read interesting contents you come back more often. Additionaly if you know real friends here you return. Why facebook is so popular just because you know people. You invite people who know and you are invited by people who know. In hubzilla the invitation process is too basic and too hard to use.

 

Now I would like to propose few directions. I know developpers are all volonteers and give free times to hubzilla. But adoption of hubzilla is not only the work of developpers and even more hub administrators but this is a job for all. We can all write about hubzilla everywhere. More you write about it more it will be known. This is the evangelism.

But I am conviced that hub administrator have the main role for that. Each community have an administrator and even moderator. His role is really important. The adoption of hubzilla has no means. But the adoption of specific hub is different. Each hub should have specificity. I mean public hubs. You can compare a hub at forums. Do you remember phpbb. If you launch a forum and do nothing, no body will come. But if you define the subject, and invite people and try to put a content inside that will attract people. Exemple forum about astronomy. You can invite all passionate people. With hubzilla you can do that. Create public forums private forums and invite people passionate whit it. General hubs is nice but specific hubs are better. When people have one zot account they don’t have to have a second one for football forums for exemple or private discussion with family etc… Each administrator should makes the effort of attracting people, they should explain the advantages.

Administrators are the key users between members and developpers. They should be empathetic and understand how users feels and what they needs. They should have idea how to improve simplicity, ergonomy., virality and fidelity. Sometimes one little things and do huge difference.

 

Older posts «