M. Dent
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

M. Dent
!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"?
Marshall Sutherland
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?
Erik R
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 :)
Erik R
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.

M. Dent
!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?
Andrew Manning
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.
M. Dent
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.

M. Dent
!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
Andrew Manning
Pretty cool stuff. I hope someone uses it one day and shows us a demo.

M. Dent
  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.
M. Dent
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?
Waitman Gobble
@Mike Macgirvin answered that same question for me before. it was a thread about zotid. ill look it up
Mike Macgirvin
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.

M. Dent
!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.
Mike Macgirvin
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.
M. Dent
  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.

M. Dent
!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.

M. Dent
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)
Mike Macgirvin
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).

M. Dent
!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?
Mike Macgirvin
Settings -> Addon/Feature Settings or whatever I changed the name to recently.
M. Dent
I knew I had seen it.... Thanks!
M. Dent
!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).
Mike Macgirvin
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.
M. Dent
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)
M. Dent
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.

M. Dent
!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"?
M. Dent
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".
Mike Macgirvin
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.
M. Dent
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.

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


meet the new boss...

M. Dent
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+

M. Dent
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+
With Hubzilla, I am always drawn back to its privacy options, security, many features and possibilities, after playing elsewhere.
Einer von Vielen
... I feel save to share photos, calender and thoughts with my family
...I feel getting the oportunity offerd of being within intersectional communities within an online space where I have the power to decide about my data. Now we just need other groups using it for that purpose too.

M. Dent
  last edited: Thu, 12 Apr 2018 14:50:24 -0400  
From a comment on another thread:

One reason Hubzilla isn't as successful than other community systems is IMHO the concept itself. The community is not at first place but creating websites.

Reference:  https://project.hubzilla.org where it states
Hubzilla is a powerful platform for creating interconnected websites.

@Hubzilla Advocacy+

(HT: Holger for the question!)
M. Dent
Mario VavtiMario Vavti wrote the following post Thu, 12 Apr 2018 14:54:42 -0400
The marketing of the software is directed towards people which build communities not towards the actual community members.
Mike Macgirvin
The marketing of the software is directed towards people which build communities not towards the actual community members.

This was an important concept four years ago. I'm not sure I'd stick with it. Maybe yes, maybe no. They (community builders) turned out to be a pretty fickle bunch.  Let's take a survey of those that are now creating sites and see what their common purposes are.
h.ear.t | tobias
  last edited: Fri, 13 Apr 2018 02:10:37 -0400  

M. Dent
!Hubzilla Advocacy

Sorry to clutter your feed. Trying to track an elusive behavior on my hub.

M. Dent
Here's the introductory post with a link to the new forum.  Like, Link, "Share and Enjoy!"

Hubzilla AdvocacyHubzilla Advocacy wrote the following post Wed, 11 Apr 2018 11:11:47 -0400
There are a number of groups that already exist in an effort to support the Hubzilla ecosystem.  Support and Development discussions have their own channels.  But I haven't found a channel specifically designated to the discussion of strategy and planning to advocate for the platform in a cohesive, sustained fashion.  Seeing the need, I created one.  WELCOME!

This is a space for Hubzilla "evangelists" to discuss and strategize plans for advocacy of the Hubzilla platform.

I'm not big into rules.  Aside from human decency in discussion and behavior, there is one guideline regarding the goals and purposes of this space.  This space is to gather together those who wish to advocate and work on gaining new members in the ecosystem AS IT IS.  It is  NOT a place to whine about lack of features, usability, or other issues.  Some leeway will be given under the heading of "hurdles to adoption."  But "if onlyism" will not be tolerated.  ("If only we had xxx feature/yyy got fixed/zzz were true.... then adoption would skyrocket!"   Whether or not the statement is reasonable or even provably correct is irrelevant.  Whatever comes after, "if only," is not what exists today and this group is about promoting and building a user base for the platform AS IT EXISTS TODAY.

The platform as it exists to day is usable, robust, and has much to offer.  I constantly find something new within the platform as it already exists that blows my mind and is extremely useful.  No, it isn't always easy to do.  Yes, Hubzilla expects a lot from it's users -- and that is a GOOD THING!  It means the devs and those involved in the project aren't the "high and mighty," glass house, ivory tower types who look down on everyone else.  They believe people are intelligent and capable and can be responsible.

As time goes on and we gain a core group of evangelists, hopefully this will be a robust place with a lot of ideas and resources for those who may not be able to participate in down and dirty development, but love the platform and wish more people would use it.

EVERYTHING can be improved upon.  Route your suggestions for improvement to the proper places - or, better yet, figure out what you, personally, can do to make it happen.  But this is NOT the place for those discussions.

M. Dent
!Hubzilla Support Forum
Is there a mechanism to pin a post to the top of a forum channel?

Also, it there any thought or plan (or old code) for a more traditional "forum" layout (clickable topic/title list that brings you to the post and comments)?
There has been a discussion about points content, but I don't think it has gone any further than that.

For the forum, yes you can set the channel to display just the originating post and a link to comments, cannot recall the name of the option but it should be under display settings...
It's something like "show you channel in blog mode" or similar
M. Dent
Nice!  Thanks!

M. Dent
!Hubzilla Development

It's bound to happen, and I don't know what's in existence to deal with it or what may yet need to be developed.  We all know there are "bad actors" who will try to use an interconnected platform for gain in various ways, especially if adoption rates go high enough (which is always our hope, right?)

With great power comes great responsibility, unfortunately, not everybody is responsible to wield the power of an interconnected platform such as this.  Without a centralized authority (which we're trying to do away with), there needs to be something for hub admins and even individual channel owners to deal with problem community members. So.....

What tools exist for hub admins to deal with other bad-acting hubs as well as local and remote channels (eg., someone spins up a hub that just monitors and collects a list of "public" channels and then starts, for example, spamming public forums)?

What tools exist for individuals (channels) to deal with bad-acting hubs or other channels?

On a previous thread, there was some mention of "reputation" - and I think that sort of tool could be helpful (reputation of hubs and reputation of channels) - but for now, for my purposes, just figuring out the current state of things and seeing what holes exist is a good start.

If there's stuff in the docs already - just toss a couple of key words for me to look for and I'll read up on what's there.  If there's anything else that is in the code but not documented, that'd be helpful also.
Mike Macgirvin
For my single-user hub, superblock is really all I ever need. For admins of public hubs we've got channel blocks and site blocks, and unlike "tag following networks" there is a human behind every public forum that can moderate and bounce bad actors. The default permissions (connections only for most things) keeps out a lot of riff-raff.

I also know that these aren't adequate. One of the first public sites had a hell of a time with somebody creating hundreds of spam channels. The only saving grace from that episode is that since nobody ever friended the spam channels they weren't very effective in spamming.

Unfortunately, we'll probably have to wait until somebody throws us something we can't easily deal with before we perfect the tools to deal with it.  On the short term you can block any of your connections that are leaking spam or bad behaviour into your channel or send them to affinity 99.

If the community assumes that the mythical 'devs' are going to solve all their problems, we could end up with some hard learned lessons. The only thing that traditionally keeps bad behaviour in check is tight-knit communities that work together.