• Если вы хотите иметь свой собственный хаб но не имеете достаточного опыта администрирования веб-бэкэндов подумать сможете ли вы потянуть эту задачу. Ничего особенно сложного, но, всё же, надо иметь базовые навыки по конфигурированию и отладке.
• Если вы таки решились его поднять, то, разумеется, вы должны ознакомиться с руководством по начальной установке и настройке из исходных кодов Hubzilla. Точное следование им почти всегда гарантирует успех.
• Если после этого у вас есть вопросы, то рекомендую обращаться к англоязычному форуму хабминов (да, вы теперь так называетесь) @Hubzilla Support Forum начав с чтения архива где с 99% вероятностью уже есть ответ на ваш вопрос. В крайнем случае плохого владения английским (прим. авт. а зачем вы тогда хаб поднимать полезли?) рекомендую писать в русскоязычный форум @Мы говорим по русски.
• Если вы простой пользователь то к вашим услугам, во-первых, документация на Hubzilla которая на вашем хабе расположена по адресу /help. Вам может быть полезен форум пользователей @Hubzilla Users Support и русскоязычный @Мы говорим по русски. Также можете ознакомиться с несколькими статьями на русском о специфике отдельных функций Hubzilla здесь https://tiksi.net/wiki/net.
• Если у вас вопросы связанные с работой и функционалом (его нехватке) на вашем хабе, то обращайтесь к его администрации. Для моих хабов для этого могут (и должны) использоваться каналы @tiksi@net и @Zotum.
• Если после тщательно изучения и общения следуя вышеупомянутым процедурам вы уверены что обнаружили ошибку или хотите получить новый функционал в Hubzilla то для сообщения об этом используйте стандартный механизм в репозитории проекта https://framagit.org/hubzilla/core/issues. Разумеется, на английском.
• Не следование вышеизложенным принципам будет расцениваться как неуважение к сообществу.

• Using direct push transfer instead of the notify/pickup delivery model.
• Inclusion of ActivityStreams (JSON-LD) as a supported (primary) serialisation.
• Dropping the requirements for implementations to support secondary serialisations.
• Moving service discovery to "Accept-header" based service endpoints where different representations can be selected by modification of the HTTPS request accept header.
• Separation of the portable-id from the signature algorithm used.

• The photo cache addon provides the photo cache app which can be enabled per channel and increases anonymity in the world wide web. Public photos will be cached at your hub.
• The queueworker addon (admin only) implements an enhanced queue worker. This is only important for site admins. The addon is still marked experimental but does a pretty good job already. It has the potential to improve queue handling especially for big sites.
• The gallery addon provides the gallery app which has been enhanced and has now extended functionality: photos in posts/comments can now be viewed in the photo viewer directly from the stream and and images at the beginning of a post will be converted to an album.
• The TOTP addon provides per channel two factor authentication using timebased one-time passwords.

Howto Upgrade

• Hubzilla 4.0 requires PHP 7.1 or higher. Versions 7.2 or 7.3 are recommended.
• HTTPS is now mandatory.

1. util/safemode on this will disable all enabled addons
2. util/udall the actual update which executes git pull for core and addon repos
3. There are several DB updates which can take a looong time (depending on DB size) to complete. Please be patient. If updates fail due to server timeout, you will need to apply the failed updates manually.
4. util/safemode off this enables the previously disabled addons again
5. Install the upgrade info addon (optional) - this will show some info about the upgrade to your community members

• Would the Hubzilla users among us recommend a certain pod? And if so, do you have reasons for your position?
• Is it possible to migrate contacts from d* to h? (That's the crucial one. I'd hate to recreate the whole list of almost 700 contacts.)

• Prevent incompatible export files (osada/zap) from being imported
• Catch exception if readImageBlob() receives bogus data
• Streamline PDF previews
• Allow notification filtering by name or address
• Fix too restrictive attached photo permissions
• Update ES translation
• Use flex for the default template
• Do not store serialized pconfig value received via to Module/Pconfig.php
• Update jquery-file-upload lib and move to composer
• Update imagesloaded lib and move to composer
• Fix activitypub tag notifications
• Fix call to undefined function in PConfig
• Fix typo which prevented propagation of comments to zot6 (dev)
• Activitypub: add support for pterotype (wordpress plugin)
• Openstreetmap: check validity of lat+lon before rendering a map

• Diaspora is completely incompatible with Zot6. We will do everything in our power to preserve connectivity to that network, even though at this time I don't have a solution for how exactly to accomplish this. Diaspora is incompatible with ActivityStreams and Zot6 is built on ActivityStreams. Don't fret. It's not going away.  I'm somewhat confident that we'll find a compatibility solution in the next month or two, although it's very likely it won't be very efficient. Since Diaspora actually doesn't federate with anything (other projects federate with it), it will be on us to find a workable solution.
  
• Mail. Zot6 does not support 'mail' as a separate messaging system. Private messages are sent as private messages, not as 'mail'. We will do our best to create an interface to display these separately from your normal stream. Some will be surprised at this decision since I have fought it vehemently for years, but the simple truth is that mail as an interface has always gotten the short end of the stick and always falls behind the social stream in innovation and features and upgrades. Zot6 privacy is respectable and very well tested.
  
• Reshares. In Zot6 as in many other networks, reshares are single click activities (much the same as a 'Like'). In older zot implementations a reshare is an embed of another post into your own post and commentary is permitted. It isn't clear yet how to resolve this discrepancy. We will be favouring the popular implementation over the older Hubzilla implementation, but we haven't yet decided how or if to migrate existing content. This is where other developers might have a chance to show their stuff. It's not much different than the email choice to "forward inline" vs. "forward as attachment". It would be nice to offer a choice, but I won't sugar coat it - it would be a fair chunk of work.
  
• Permissions. In Hubzilla we reworked the entire permission system a year or two ago to make it more extensible. That was a major improvement, but it wasn't quite enough.  Zot6 has a newer permission system that is much more flexible. As of this moment, we could go either way - keep the old one or move everything to the new one. I'm tempted to move everything forward, but this could delay the completion of the zot6 integration by a few weeks. At this moment, I'm saving that decision until I see how the rest of the migration goes. If we lose a month dealing with Diaspora quirks, I probably won't be able to update the permissions and we'll have to put that off until a later release.
  
• Object encoding. The way post meta-information is encoded on disk in Hubzilla (an older variant of ActivityStreams) isn't compatible with ActivityStreams-JSON-LD which zot6 uses. Several metadata field names are different. Migrating existing content could take months to code and test and will most certainly involve up to several days of downtime on large sites, so this will not happen. We'll continue to store this metadata in the current format and translate it to the new format on the fly when required.