!Hubzilla Advocacy

This is good news in a number of ways for tools like Hubzilla.   What do you think are the reasons for such a shift?

Reddit surpasses Facebook to become the 3rd most visited site in the US


According to Alexa – the Amazon-owned web traffic analyzing platform – more people now visit Reddit than Facebook in the US. Spotted, of course, on Reddit by user IamATechieNerd, the stats will be a big boost for the social sharing platform, especially with many users still irked about the recent re-design. It’s important to note that analyzing web …
Surprising, in a way. I wouldn't have thought it.
I never visited reddit I even don't know what it is :D

!Hubzilla Development

Looking through the docs, I'd like to make sure I understand the actual flow of events on a message.  If someone "in the know" could verify (and/or correct!) the following, I'd be appreciative...  

CONTEXT: Non-public message - privacy group "assigned"

1) Message is transmitted via HTTPS from sender web browser to sender hub
    * Effect:  message is encrypted in sender web browser and decrypted at sender hub - meaning it exists in plain text for processing on the sender's hub
2) Message is encrypted into ZOT packet (cxref:
   * Effect: data encrypted, decryption key and initialization vector are encrypted with RECIPIENT public keys
3) ZOT packet(s) distributed to recipient hubs

What I'm not clear on is when/how the data gets decrypted - I infer that it is stored in the database in the format received and decrypted on the hub prior to being sent to the recipient's web browser over SSL (the reverse of the sending process) - is this correct?

Also - what is the possibility of moving the creation of the ZOT packet (and the decryption of the ZOT packet) to the browser rather than happening on the hub itself?  It would certainly make the hub more efficient by removing the encryption/decryption processing.

What I'm mentally toying with is something like the way a blockchain based fully distributed wallet works - the private key stays local to the user and never gets stored centrally.  Obviously - lose your key - lose access to your data... but I'm not sure that's too great a price to pay... after all, with crypto wallets - lose your key, lose your $$$!

What would the biggest hurdles be to such a change in the location of the encryption/decryption processing?

!Hubzilla Advocacy

You Can’t Opt Out Of Sharing Your Data, Even If You Didn’t Opt In


The Golden State Killer, who terrorized Californians from Sacramento to Orange County over the course of a decade, committed his last known murder in 1986, the …
Thank you for sharing this!

!Hubzilla Development

Just submitted a PR for a submodule for the CART system.  Here are the notes:

Submodule to add a service type of "hzservices" to the catalog.

"hzservices" is an item type that allows configuration changes to Hubzilla when items are purchased and fulfilled.

Currently implemented: Add buyer as connection. Add buyer to privacy group.

Add buyer as connection: Buyer channel will be added as connection to the seller channel when item is fulfilled.
Add buyer to privacy group: Buyer channel will be added to the selected privacy group on the seller's channel when item is fulfilled.

Incomplete: Deactivation/rollback commands. Though deactivation/rollback commands can be configured, the code to automatically remove connection / remove from privacy group is not yet implemented.
That's weird.  I don't see get_pconfig on 1471....

I do have a get_pconfig on line 1474 both in redmatrix/hubzilla-addons:dev  as well as in the branch in the dentm42/hubzilla-addons:cart-hzservices-pr branch.

Are we both looking at the same revision?

(what does your line 1471 read?)
My bad, i have been in wrong branch. Anyway, i am on the right branch now and experience issues related to {get, set}_pconfig() not having enough arguments in /submodules/hzservices.php
get_pconfig() requires 3, set_pconfig() requires 4 arguments.

Affected are lines 29, 41 and 31, 48
(I really need to get a php7 dev environment working!...  5.6 warns but works, I forget 7 chokes entirely on those.)

Good thing, though, since it was looking at the profile config instead of at the system config for those values... that would have been a beast to figure out when someone tried to use it later!

Anyway - another PR is submitted - should fix it.

Chinese Journalist Banned From Flying, Buying Property Due To 'Social Credit Score' - Slashdot


When Liu Hu recently tried to book a flight, he was told he was banned from flying because he was on the list of untrustworthy people. Liu is a journalist who was ordered by a court to apologize for a series of tweets he wrote and was then told his apology was insincere. "I can't buy property. My child can't go to a private school," he said. "You feel you're being controlled by the list all the time." And the list is now getting longer as every Chinese citizen is being assigned a social credit score -- a fluctuating rating based on a range of behaviors. It's believed that community service and buying Chinese-made products can raise your score. Fraud, tax evasion and smoking in non-smoking areas can drop it.
!Hubzilla Advocacy

Why would businesses want Facebook culling through their internal business communications?!  Here is definitely an angle for Hubzilla in terms of marketing and advocacy.


www.washingtontimes.com stories: Nationalwww.washingtontimes.com stories: National wrote the following post Fri, 20 Apr 2018 19:42:12 -0400
Man killed in random knife attack at California steakhouse
Man killed in random knife attack at California steakhouse

LOS ANGELES (AP) — A homeless man is facing a murder charge in what authorities say was a random attack on a California father, who was stabbed in the neck as his 5-year-old daughter sat on his lap in a crowded beachside steakhouse.

Jamal Jackson, 49, was charged with first-degree ...

!Constitutionist News

!Hubzilla Support Forum

When linking to an RSS Feed on a multi-site blog, the profile for the connection gets populated with the author info of the first post ever downloaded.  Is there a way to override the profile information on at least some connections (like RSS feeds) in order to fix things like this?

Also - (likewise for RSS feeds) - is it possible to make RSS Posts "shareable"?
Feed-mostly public sounds familiar. When first set up, I find that the feed channel, itself, will have some number of historical posts, but my channel only sees new posts as they come in from that point forward. Could this be what you are seeing? It doesn't sound like it, but I thought I should ask.

When I set up the feed channel, there are a couple of steps. Maybe one of them is missing.
I'm sure you have the connection to the actual feed, since you see something
Your feed channel needs to have the Channel Sources feature (in Additional Features / Post Composition Features) turned on.
That will give a new setting page called Channel Sources. On that page, you need to add that connection (the connection to the actual feed) as a source.

Have all those things been done?
I never added the feed-channel as channel-source on my main channel.

I agree that only new items in the feed will show up so I figure I will know tomorrow :)
I never managed to add the feed as "Channel source", instead I just connected to the feed and the content shows up in the feed-channel-wall (home).

I sadly lost all content of the feed-channel when I changed from feed-mostly public to what-ever and back. The feed is updated once or twice a day so I have to wait.

!Hubzilla Development

Is there any example code for the bbcode_filter and bbcode hooks?  I see them in the bbcode function (include/bbcode.php), but I can't find them used anywhere.  I'm thinking of creating a "buy-it-now" type button for the cart tool that would add an item to the cart and take the user to the beginning of the checkout phase.

Maybe something like:
[zcart=buynow][item]##[/item][buttontext]Buy it Now: $10[/buttontext][/zcart]

So.... if I were to create a custom bbcode tags, which hook should they reside in?  Or is there a better way to do it?
Looks like you would process the text like the previous statements do:

    if (strpos($Text,'[/zcart]') !== false) {
        $Text = preg_replace("/\[zcart\](.*?)\[\/zcart\]/ism", 'whatever you want', $Text);

where you would add more logic than this to parse the "buynow" string and decide what to render.

It looks like the primary difference between the two hooks is that the "bbcode_filter" hook executes prior to further BBcode parsing, while "bbcode" is the final processing step so you can be sure nothing else will change your output.
That's what I thought... just wanted to make sure I was working in the right direction - or find out what the "right" way to do it is if I was working in the wrong direction.

!Hubzilla Development

Weighing in at just under 2050 lines of php (plus templates), the core functionality for the cart plugin is complete (includes sample catalog, basic shop administration tools, and manual payment system)

I'll be the first to admit ---> It ain't pretty, but it is functional.  

As before, there is only the example catalog and manual payments but the basic shop admin tools are now functional and allows a shop owner to manually kick off the fulfillment of items, mark orders as paid, and make notes on both items and the order as a whole.

This is basically the CORE plugin.  It acts as a traffic director and tracker for the progress of the order.  It is designed so that MOST functionality will be handled by additional add-ons in the following categories:
   * Catalog/Items - these plugins will create new item types and contain the code for the core hooks to call to "fulfill" items (make them active, connect with outside services, whatever needs to be done)
           * Example:  Hubzilla "paid extras" addon to activate additional features or provide access to pages/forums/etc. upon payment.

  * Payment Processors - these plugins will hook into the payment flow and kick off the order fulfillment process once an order is paid.
           * Example: Paypal

Other possibilities for addon modules include:
  * Subscription/recurring payments
  * Customer Service / communications

There are also hooks that allow for the entire UI to be completely replaced by an enterprising community member.

Here is a sketch of the VERY basic usage instructions (once installed and activated)

Base URL: /cart/<shopchannel>
Catalog URL:   /cart/<shopchannel>/catalog
Shop Admin:  /cart/<shopchannel>/myshop
Pretty cool stuff. I hope someone uses it one day and shows us a demo.

  last edited: Fri, 20 Apr 2018 00:48:14 -0400  
!Hubzilla Development

The context here is the cart addon.  At some level there is a need to have access to at least SOME info about the purchaser - especially for customer service purposes.  But after mucking about in the code, I can't figure out what information the seller should rightly have access to and how to properly obtain it so that there is no inadvertant leak of private data.  I'd prefer not to force a remote profile query every time there is a search done - that seems wasteful.  But I don't want to store info that could later be leaked or misused.

As it stands, the order table stores the channel hash of the purchaser, but does not directly store any other information about the purchaser.  I'd like to maintain whatever "boundaries" already exist regarding access to profile data and would rather not expose anything even if it happens to be in the data tables on the storefront's hub.

So... what information can I get about purchasers using the existing tables in the storefront hub and what is the "right" way to get it?  Is it appropriate to simply query the xchan table directly?  If I have the channel hash, is there a proper way to grab the profile without making a remote request to the purchaser's hub?  Is there another place this info should come from?  My goal at this point is not to store more than absolutely necessary in the order table - data that isn't stored can't be leaked, after all.
I guess this brings up an interesting question.  What is the ONE thing that is the base "identity" within Hubzilla?  I chose channel_hash because of the possibility of a person deleting their account and someone recreating an account on the same hub with the same name.  Since channel_hash is based on guid and (if I understand things correctly) is shared among clones of the same identity, that seemed the correct choice.  Did I get that right?  Or is there something else that should be used that is (1) globally unique to the identity and (2) preferably shared among clones?
@Mike Macgirvin answered that same question for me before. it was a thread about zotid. ill look it up
The hash is the unique id. Finger::run is a wrapper which currently only uses the address, but
https://hub.webgoeslocal.net/.well-known/zot-info can lookup a channel by a few different parameters.

Refer to include/zot.php:L4202

You can send either 'guid_hash' or 'address' as a request variable. You can also send the guid and guid_sig from which we derive the hash.

If you don't include authentication or a sender channel, the endpoint will only return public information. This would be the simplest method - curl fetch https://hub.webgoeslocal.net/.well-known/zot-info?f=&guid_hash={{hash}} and json_decode the result. The f is a dummy variable that we almost always use to work around a bug in some versions of Apache/mod-rewrite.

!Hubzilla Development

Based on the discussion started by RockyIII on the support channel:

As I'm reading Mike's comments on the RockyIII post in @Hubzilla Support Forum  :

if you enable federation you basically can't really use anything that makes Hubzilla great. Nomadic identity doesn't work. Privacy controls on most anything don't work (photos, media, webpages, wikis, chats, events, whatever) because people in other networks cannot access them.

It dawned on me that "Federated Hubzilla" and "Zot Only Hubzilla" are really two different things in some very significant ways and yet we don't really actively distinguish this.  Rather we tend to talk about this single thing, "Hubzilla".

While the internal workings of Hubzilla are the same, the effects of Federation make for a very different user experience.  For example, it sounds to me like "privacy groups" in a federated environment, really aren't "privacy groups" at all but merely "distribution groups."  Is that correct?

One thing that may be considered is to recognized the reality that "Federated Hubzilla" and "Zot Only" are truly distinct and find ways to make that more clear in our conversations (perhaps even having a separate "Federation Updates" in release notes/etc.) and perhaps also do some things from a UI perspective.  The basic message that seems to need reinforcing is, "Federation changes what you should expect from Hubzilla."  If this is so, by making our language clear about it, we would be able to talk more directly about the tradeoffs and how to manage those tradeoffs.  It also would give us a way to more clearly define "the main thing" about Hubzilla and keep that "the main thing."

Such discussions may even find it's way into UI elements that make the behavior differences clear.  For example, if my assertion above is correct (that Federation essentially makes "privacy groups" into "distribution groups"), perhaps add a  "Federate" toggle to the right of the submit button.  The effect of the toggle would be:  (1) Produces a popup that makes clear that "Federated" items are fundamentally PUBLIC items that (in some cases) may be restricted in distribution by choosing a "distribution group".  (also giving an option, "hide this warning in the future")  (2) For those things where it makes sense (eg. posts), change the LOCK icon to something of a "group of people" icon showing that you are not choosing "privacy options" you are choosing a "distribution group". (3) For those things where making an item visible to the Fediverse requires the object to be PUBLIC and a post will not be generated by the action, remove the lock icon entirely and simply sets the ACL to Public.  (4) Perhaps change the color of the textbox background (for posts) to indicate the choice to use a less secure/private distribution mechanism.

Of course, these are just thoughts, and are predicated on a specific understanding of "how it works"... so feel free to correct me or slice and dice as needed to reflect reality.
Last year we separated the two into server roles (basic, standard, and pro) and this confused people even more. So we merged these all back together and are trying to present one unified hubzilla. The problem is our audience. We get way more adventurers from the federated web than we do from our target market (community builders) and all they tend to see is "social network with federation". That is their chosen worldview filter. It's obvious that our messaging is not reaching them, but it's even more difficult to fine tune our messaging in response because for the most part they are filtering this messaging and only seeing the bits they wish to see.

You've got some excellent ideas - and I think we should probably experiment a bit with them. I'm just worried about making things even more complicated since some people would have one type of ACL behaviour and some have another.
  last edited: Fri, 20 Apr 2018 09:36:46 -0400  
I wasn't really advocating for a different behavior of the ACL.  Just make clearer what the actual behavior is.  I suppose there is technically little difference between a "distribution group" and a "privacy group" under the hood.  The item itself (eg a post) will still only go to those on the list, but attached resources (eg, photo) will not be secured.  The "fediverse" toggle is basically an alias for "make the attached resources public".

I suppose another option there would be to create tokens for each person on the distribution list on a federated post and have it modify the URL of included attached items for outgoing messages.  But that would only work for things originating from Hubzilla. Based on reading your conversation with Julian, I have no idea how that could be made to work if the message originated on another network.

!Hubzilla Development

Following along with RockyIII's notes in Support - and decided to create a new account and check out the "New Member Links" menu on the right sidebar.  One thing I noticed was that the right sidebar collapsed and was hidden from even with a reasonably wide screen (disappears at 1180px width)  and becomes inaccessible and invisible (which makes it completely inaccessible and therefore useless for smartphone users - and I use the webui all the time on my phone --- it's GREAT!).  The left menu goes away at 980px, but the slider arrow (->) appears in the top navbar.

I am SO not a UI person, so I'm not sure I have any good suggestions.  My first thought (partially because I think would be fairly easy to implement) is to "fold" the right menu and make it visible at the top of the left aside when it is removed from the right.  But I'm sure someone here has a better idea than that.

According to the member guide, RSS feeds usually poll once or twice per day.... I can't find the admin setting that sets how often they poll (is there one?).  Currently, it appears mine are polling according to the TTL in the RSS feed which is 1 hour (plus the delay of the cronjob).  Is there a way to administratively reduce the poll interval at this point?

!Hubzilla Support Forum

(ugh. sorry for the dupes... still trying to keep track of posting to forums vs. private page)
util/config system.minimum_feedcheck_minutes

Default is one hour if unset, and can also be over-ridden by the service class variable minimum_feedcheck_minutes if you want to allow paid members to have more timely response to feed changes than free accounts (for instance).

!Hubzilla Development

I've been playing with the affinity slider and "prioritizing" my contacts.  I REALLY like it.  The only thing I don't like is that it isn't sticky and I don't see a way to set a default.

My preferred thought is to simply have the value stored as a default in the profile whenever it is changed - maybe with a profile setting, "Affinity Slider - Remember Last Setting" or something.  Another option is to put a default range in the profile settings.

I'm guessing this has been discussed before, so I'm happy to defer to the previous conversation, if so.  If not, are there any thoughts to this?
Settings -> Addon/Feature Settings or whatever I changed the name to recently.
I knew I had seen it.... Thanks!
!Hubzilla Advocacy


I procured the domain usezot.com and set it up with an SSL Cert (Let's Encrypt).  Currently it redirects to https://project.hubzilla.org

Hopefully nobody objects (if they do, I can remove the redirect).
I gave up getzot.com a year or two ago and whoever was squatting on it let it expire last month. So another few weeks and you can probably get that, if you want.
It looked like that was the case, then it looked like the registrar had it locked until 2019.  I wonder if they paid the extra to recover it? (Or I read the who's info wrong - I'll have to recheck)
Read the whois records wrong.  I was looking at several domains and must have mixed them up in my head.  I'll try to keep an eye on it and nab it.

I've also nabbed zot.social as a cheap introductory price.... renewals aren't as cheap as I'd like but won't break the bank.  Just leaving it parked for the moment.

!Hubzilla Support Forum

Kind of an odd question:  Is it possible to have a "private" directory server?  That is, a full directory server that only serves certain hubs.  Or is it necessary for a directory server to be "non-discriminatory"?
As I understand it, that is to set up a private grid.  What if I want to be part of the standard, global realm (not a private one), but only allow certain hubs to use me as a directory server.  For example, if I wanted to create a "pay-to-play" directory server for faster response to those hubs that support the costs of the directory server (or otherwise support the community), but still connect to the rest of the standard "grid".
You could use the standard directory server mode for that but using the realm_token that private directory servers use. If you don't use the token you can't connect to the directory services. It isn't highly secure but is suitable for what we needed it for. Might be a very minor amount of coding since we already support the realm_token but I think only when the realm is different from the default.

And it might require a new directory mode because we don't currently have any way of telling somebody that a directory requires a token except if it's setup in a realm - where you'll find this out from the realm provider when you try and configure it.

Our standard setup is non-discriminatory when configuring a directory server for the first time and choosing one from the admin dropdown. So these two functions would need to know there was another option.

In any event, those are the tools we currently have. I'll let you decide if you can make that work.
It's just a conceptualization at this point ...

I'll take a peek -- it isn't on my high priority list, or even mid-priority list at this point.  But it was something that came up in my thinking as I was considering what angles people might want to use to monetize and support a larger implementation/installation or network of installations - and a way to support the community as a whole by having a suitable pool of directory servers as things grow.

Constitutionist NewsConstitutionist News wrote the following post Fri, 13 Apr 2018 22:52:11 -0400
Tyge Gaul


meet the new boss...

Andrew ManningAndrew Manning wrote the following post Thu, 12 Apr 2018 21:49:51 -0400
Introduce privacy into your online life
Most people who use web services have no idea how privacy works in the digital realm. This is primarily due to the fact that the services and software they use do not support their privacy. This article provides an introduction to some of the basic concepts of privacy and guides you in ways to bring some privacy to your life online.

Webpage form: https://hub.reticu.li/page/andrewmanning/privacy-online

@Hubzilla Advocacy+

h.ear.t | tobiash.ear.t | tobias wrote the following post Tue, 10 Apr 2018 16:26:36 -0400
Hubzilla Channel Roles - An Overview
When you register at Hubzilla you are presented with a choice of channel roles. There are
  • social channels with varying privacy settings
  • forums with varying privacy settings
  • feed channels
  • a soap box function for announcement only channels
  • group repositories

The docs explain the basics about what is what, but I was always missing a tabled overview. So I created one.


Nicely done!

@Hubzilla Advocacy+