cover photo

Hubzilla Development

  last edited: Thu, 02 Nov 2017 16:45:30 -0400  
The help pages contains not only texts in different languages. The content of [1] and [2] is also different. Is it intended, those URL /address design for [1] and [2] to offert? I suggest one consistent URL/ address syntax for help and other Hubzilla pages to design and to apply. S. also subject: serverside delievery of appropriate language-sensitive pageversion worsened searchengine ranking .

In my opinion, is it usefull, when Hubzilla user can for the Hubzilla help the external searchengines of its choice to apply.

@Hubzilla Support Forum+ @Hubzilla Development+ #HubzillaHelp #searchengines #externalSearchengines
  last edited: Thu, 02 Nov 2017 12:58:58 -0400  
@Andrew Manning
I encourage you to step back and ask yourself why you want to spend time working on this particular component of Hubzilla.

Yes, I want that all
  • will have to do a part of it all work self. I will have to contribute as developer - what I can to do.
  • bring new developers to the Hubzilla community who wish to work on it with you - s. my LVEE 2017 engagement bottom in this post
  • help people who are already using Hubzilla and you want to make the doco more accessible or useful to them? - s. Heliza project Considerations for Hubzilla mobile agent concept
  • improve the language translations for non-English speakers - I will be make a russian version of still previous 06-22-2017
  • introduce Hubzilla to new people and encourage them to use the software - s. LVEE 2017 and my Hubzilla promotion for german speaking contemporaries
to do. I see that all this tasks, all this activity as part of one projects with the one major goal Digital space for livable public space to design and to develop. I present Hubzilla on LVEE 2017 conference (“Linux Vacation / Eastern Europe) June 23. - 25.06.2017
LVEEE combines both communication and rest of the enthusiasts of free software, including GNU/Linux platform, but not limited to it.
LVEE 2017 is organized by Minsk Linux Users Group with support of the open source community active members from other cities. Recommended Conference languages are Russian, Belarusian and English.

I was invited by the organisers speak about Hubzilla on LVEE2017 conference. Here summary for my LVEE2017 speech (and maybe one Hubzilla Workshop on LVEE2017).
I am pleased for you about goals, the philosophy and historie of Hubzilla project, the unique features of dezentralized Hubzilla Grid to speech, about possibilities of solutions with Hubzilla Nomadic Identity and aceess control with fine-grained permissions for information shared across the Hubzilla grid and about them how Hbzilla community and myself are working continuously at the achieving the objectives of Hubzilla project and realisation of creative ideas in reliable and comfortable solutions.
I saw the topics of other LVEE 2017 participants and competences, skills and knowledge of other participants and hope, that  during the Conference will be to make new contacts, there will be further developed - also in Hubzilla space. Other participants have so many interesting topics - I am pleased for live communication an LVEE 2017 and new acquaintances.

When yo want support my activity for Hubzilla Promotion, you can donate for frekonale e.V. Each donation, even the smallest one support me in my Hubzilla engagement. The trip to LVE2017 to the Republic of Belarus pay I of myself own pockets.

You can donate for my Hubzilla engagement for frekonale e.V. . The doanations are tax-deductible:
Donation account: GLS Bank, IBAN DE24430609671174433900
Purpose (Verwendungszweck) "Hubzilla connected people"
Vereinsregister des Amtsgerichts Dresden: VR 7811
Steuernummer Finanzamt Meißen: 209/141/05774

#LVEE2017 #minsk #belarusian #weissrussland #LinuxVacation #EasternEurope #nonEnglishSpeaker #frekonaleeV #RepublicOfBelarus #belarus #frekonale #DE24430609671174433900 #grodno #hrodna
"Visibility" oft the comment oft @Mike Macgirvin : I can see his comment. My Hub runs Hubzilla Pro.
  last edited: Fri, 26 May 2017 23:15:14 -0400  
@Andrew Manning
I can't speak for other people, but based on my knowledge of the Hubzilla community, there will probably not be anyone else who will volunteer to write code with you.
Some considerations to that:
  • when I and other user the Hubzilla RC's test and write I bugreports, is it not for me, but for me and also for Hubzilla community. I mean debugging is also one job, wich not little important is by comparsion with programmer job ;-). Hubzilla community can a lot more achieve, when potential synergies will be systematically to identify and consistent to use
  • I am interesting on constructive feedback to my ideas and on solution approaches to realize my ideas.
We seriously need to add some pizzazz to the Features section of the #doco. If anyone would like to make some little graphics or screenshots to illustrate the various features, share them using a cloud files folder, I will incorporate them into the text to make it more visually appealing.

@Hubzilla Development+
I choose "Must be on hubzilla to have a slice" privacy settings
This would be a great advertising campaign! :-)
We need to fix the #doco search, and remove the old content files that have been refactored.

@Hubzilla Development+
I've taken some space away from the #doco revision effort and let a broader audience see it in the master branch. Now I'd like to hear some feedback about what remains to be done.

  • What topics need better documentation?
  • We've come a long way in terms of the help pages interface, but are there structural changes that could make it even more accessible?

The strongest improvement we have made to the documentation system is actually the context help. One obvious improvement would be for the context help panel's "more documentation" button to take you to the relevant topic instead of just linking to There is already some code infrastructure for this, so implementation might be easy.

If you are a newcomer to Hubzilla, I am especially interested to hear your opinions and suggestions.

@Hubzilla Development+

Has anyone tried using Cordova to make a mobile app? Or does anyone have experience with #Cordova to offer advice? This might offer a feasible way to create mobile apps for Hubzilla.

@Hubzilla Development+
Interesting articles. Thanks for sharing. I must say I'm frequently disappointed by the default ease with which developers seem to surrender their privacy and control now. Consider this excerpt:

As is clearly stated, Progressive Web Apps can now be packaged into actual installable Android packages! This uses a back end Chrome server to package the website into an APK (though it is unclear if it is Google running this server, which we presume is the case).

There are a host of issues here that Hubzilla supporters immediately recognize but apparently very few others do.
Hmm, indeed, strange.
This uses a back end Chrome server to package the website into an APK (though it is unclear if it is Google running this server, which we presume is the case).

I would consider this as an show stopper for Hubzilla-Apps.

Let's update the Development Task page. It looks like @Mario Vavti updated it a few days ago. I added Mario's idea about converting the #doco to a Hubzilla wiki that people can edit locally and submit pull requests. Is everything else still current and relevant? What new ideas do we want to add?

@Hubzilla Development+
Doesn't everyone in the world think in English even if they speak strangely? No? You raise a good point, but honestly I haven't thought through even the basic mechanics in enough detail. I assume however this would work would be even easier for translators, but we have to design it deliberately to be that way, don't we? Thanks for mentioning this.
Doesn't everyone in the world think in English even if they speak strangely? No?

:rage: :scorpion: Thanks for your attention @Andrew Manning !
As for "Utopia": a bit strong, don't you think? I mean that's quite a title to satisfy. How about something bold and indicative of our principles, like Hubzilla 3: Liberty.
What about creating a new tag in our custom BBcode that allows for raw HTML? Something like
[nobb][ html ]
<div><p>Here is a paragraph</p></div>
[ /html ][/nobb]

The HTML would be sanitized of course, but since all the BBcode content is ultimately rendered in HTML anyway, is there a reason not to provide this hybrid option?

@Hubzilla Development+
I will just mention that implementing it would be fun (not!) - as we've gone to great lengths to prevent HTML from getting through bbcode(); hence we don't need to purify it. You also have to purify it on the receiving end since you can't trust the sender to send you purified code. It can be done, but it gets really messy really fast and it complicates security in a big way. More complicated security isn't the direction we'd ultimately like to go. The recent issue with html in markdown code blocks gives you an idea of the complications that could arise. Every site has to pull out this text and purify it before they can store it. Any differences in purification between sites can also lead to invalid signatures.  You're welcome to explore - but I'm just voicing my thoughts.
Nah, I'm sure you're right. If you really need that much freedom, you are probably writing #doco pages or making webpage elements, in which case you can just use HTML directly. And since I added that identity aware HTML rendering function, you don't have to sacrifice observer-dependent content. (And by "adding" I mean totally ripping off an existing function and cramming in the functionality like a cro-magnon.)

If we move our #doco to a seperate git repository, we could re-use this repository in the wiki. A symlink or a copy of it in every channels wiki folder should do the trick. Everybody could edit the doco in the builtin wiki and admins with push permissions could just cd into the wiki folder and do a simple git push every once in a while.

@Andrew Manning @Hubzilla Development+
We could put the docs into the transifex project and link the language which should appear on a hub to the choosen hub language.

With this we're able to keep the docs up to date und other hub admins can use the translations as well, almost automaticly.


I chose markdown for the API stuff because it's more or less traditional documentation with no need of bbcode.
Don't you sigh at me, boy! I can't keep track of the 500,000,000 functions you've written!
Continuing to make lots of content revisions to the #doco. In the process I'm reminded of the Affinity Slider. Is that still a thing? I personally never used it more than perhaps a day, so I'm not as familiar with it. Let's take a quick poll:

If you use the Affinity Slider, vote "Agree"

If you do NOT use the Affinity Slider, vote "Disagree"

@Hubzilla Development+
Because of this discussion I tried the slider and noticed that it didn't work the way I expected. When I move the left "me" dot to the right it hides posts from people I have set fully to the right. Somehow I expected the opposite to happen and it to only show posts from people in the black range. Maybe I really should read the docs :)

(I assume the default value if I don't set it actively is fully to the right. Is this correct?)
  last edited: Sun, 25 Dec 2016 02:47:33 -0500  
Interesting, after playing with the dots some more it started to work.... mostly.
@Mario Vavti I haven't worked much on the #doco this week, but I just pulled the latest #2.0RC and #dev branches and I like what you've done with the navigation menu scrolling. I still want a back to top button in the navbar of the narrow viewport mode, but it's not something that keeps me up at night.

Since help page content does not affect functionality or stability, is it okay if I submit pull requests to 2.0RC for content revisions?

@Hubzilla Development+
 2.0RC  doco  dev
Haven't looked in the last day or three but we could probably use the 'tags and mentions' document or a link to it in the member help.
Since help page content does not affect functionality or stability, is it okay if I submit pull requests to 2.0RC for content revisions?

Sure... Just make sure to also push to dev... Otherwise things might get lost...
  last edited: Mon, 12 Dec 2016 13:56:18 -0500  
@Hubzilla Development+
I had a look at the #doco link @Andrew Manning provided yesterday and have a few questions:
1. Why is there a separate tutorials section? I think everything informative for members should be under "Members" because people do not tend to look at several places so it will most probably not be noticed by most. Tuts relevant for users should be listed under "Members".
2. I'm missing a lot of documentation on database structure and /util/(p)config ("hidden") commands that has been extremely useful to us in the past. There should be sections for "Developers/Database structure" next to "Developers/ZOT" and a section "Admin/Manual configuration". Actually, I started to expand the manual ("hidden") configuration part, but i still have to translate my notes into english and into markdown. No need to do that if the whole section gets dumped ...
Actually, looking at the old help there's a lot more thats missing from the admins and developers section. Those sections definitely needs more entries than just "Guide" and one other.

Edit: On our hub it seems that the content is still there, just the links to it are missing. So forgive me if you are still in the process of reorganizing there. Anyway, don't integrate too much into a big "Guide" file, separate entries are better.
Thanks for the feedback and I look forward to your contributions.

Anyway, don't integrate too much into a big "Guide" file, separate entries are better.

For detailed technical information like the API functions, database schema description, configuration commands, etc I agree they should have their own pages. I'm still in the process of reorganizing content.
In revising the #doco content, I'd like to gauge how political we want it to be. There are often phrases like this:
Nomadic identity, single sign-on, and $Projectname's decentralization of hubs, we believe, introduce a high degree of degree of resiliency and persistence in internet communications, that are sorely needed amidst global trends towards corporate centralization, as well as mass and indiscriminate government surveillance and censorship.

These highlighted statements are objectively true (the "sorely needed" is opinion of course), so I'm not questioning their factual accuracy; I'm asking if we want these kinds of statements in the documentation or if they are better suited to the project website and other marketing media.

@Hubzilla Development+
  last edited: Mon, 12 Dec 2016 03:12:07 -0500  
Like my grammy used to say - you can catch more flies with honey than with vinegar.

And my corollary: Unless you want to catch mean fucking horse flies that bite. They seem to like vinegar.

But it's your project - do what you want.
But the very reason why people might actually consider using Hubzilla is precisely political: to avoid the clutches of the corporate walled gardens, and their vulgar disregard for people in general.

Again, I agree with this statement, but at least for the purpose of this post I'm very specifically talking about the /help pages and whatever else falls under the umbrella of documentation. Think of it this way: the documentation in the Hubzilla repo is installed on everyone's hub. It is likely that there are people who want to use Hubzilla but either disagree with the political statements and overtones or are uncomfortable with publicly publishing them on their website, which is precisely what they are doing. In my mind the solution here is really not controversial: remove political content from the documentation except for maybe some relatively weak statements in the section about the Hubzilla project itself (motivations, etc) so that it is clear that the statements pertain to the software project itself and not the website running the hub. Then put all the "corporate clutching" rhetoric in content designed for marketing to specific audiences (idea: someone could write a post shared on Diaspora that promotes Hubzilla as a GooFaceTwit alternative for social networking).

I'll just start submitting pull requests and, true to the honesty of open source, anyone can track what changes are being merged. If anyone feels strongly about a specific change, they can contest it then and link to the GitHub pull request from a discussion about that change that can take place on the grid.
BlaBlaNet tagged Arto's Channel's comment with ⋕???
@Mario Vavti Can you explain your headings scheme a bit more? You said
We (I) have actually reserved h1 for some special title (eg login page etc.) but it is not used yet (and it has same size as h2 atm).
Anyway, the page title has a h2 heading. This means that the headings inside the page should start with h3. Than use h4, h5, h6 for sub headings.
Again atm h3 and h4 have same size and h5 and h6 have same size. We should change that at some point and find reasonable sizes for all of them i guess.

In the case of the #doco (/help) pages, the H2 heading is the non-useful text "Hubzilla Documentation" that is at the top of every help page. The hierarchy of headings that matter for the content are in the page itself. Are you saying we must start no higher than H3? This should be okay in the sense that it provides three levels of hierarchy for the page (to H6), which is sufficient (if you need to nest deeper than that, you should just make another page!).

@Hubzilla Development+
In the case of the #doco (/help) pages, the H2 heading is the non-useful text "Hubzilla Documentation" that is at the top of every help page.

We should probably find a way to get the section title in there (maybe via argv(2)?) and make it something like:

Hubzilla Documentation: About

Are you saying we must start no higher than H3?

Yes i think so...
With the minor edits below, I am satisfied with the updates to the Help pages navigation and appearance. There are still some bugs and quirks to work out, but I would like to start focusing on revising/adding content now (not just semi-blindly consolidating content as I have been). I think this will require some coordination. Personally I think the about_hubzilla page (landing page) which includes info about the features and Zot protocol needs the most attention.

Remove classes from the #doco content region to simplify the appearance. Instead of loading /doc/, redirect to /doc/about/about_hubzilla/. These edits are minimal for demo purposes and not the proper way to do it.

@Hubzilla Development+
Actually i didn't mean <title> but the page title in <div class="section-title-wrapper">
I knew what you meant about the page title. I was saying that currently that is a static title "Hubzilla documentation", and if we wanted that to be specific to the current page, we would have to devise a method of storing and fetching page titles.
But why remove the borders? What is wrong with them?

I guess if the documentation must respect the themes then I won't remove the borders. If my personal taste is to have no borders, I suppose as admin I can install a special theme or scheme to remove them. But what concerns me more at this point is content, so I'll focus on that.
@Mario Vavti I just made a commit with a bit of JavaScript in an attempt to toggle the section folder icons. This is totally trivial and unnecessary; I was just playing around, but there's a a bug that makes the toggle fail the first time a section is selected. If you get really bored and find a better solution to this (aside from, "this is stupid, just remove the icons or leave them static") let me know.


@Hubzilla Development+
  last edited: Tue, 29 Nov 2016 11:15:45 -0500  
The only thing really important to me is that the toc is not in a seperate section but below the title.
Like in the example you posted in the other thread:

A sidenote: fixed height of the widget (like it is now) won't work well with the current theme, also not fixed position... Except maybe when you use lots of js turning things on and off. Which i think is a bit overkill for a simple (or not so simple) toc.

BTW: Please do not make use of glyphicon icons. We use fontawesome icons for the entire project...

  last edited: Tue, 29 Nov 2016 07:40:49 -0500  
A while back @Mike Macgirvin told us that he created a new #documentation organization option, where you can create a folder in /doc and add a toc.html file inside to auto-generate a table of contents for documentation "modules". I started moving the existing Member Guide content into a /doc/member folder and plan to continue do this and re-organizing a bit.

Anyone interested in contributing to Hubzilla in a way that requires almost no technical expertise should consider helping with this reorganization.

@Hubzilla Development+
This is a rapid work in progress with a lot of work left on the content. Right now there is not much stuff under the accordion menu because I decided to start the tedious task of consolidating multiple pages into larger single pages, but before that I had a bunch of individual page links under some sections (particularly Members and Administrators). The accordion menu is flexible (no pun intended); if we don't have many pages under a section, then we can leave that section open.

At the moment I'm fighting JavaScript/CSS to (1) scroll the table of contents to near the top of region_1 so it doesn't get hidden on smaller screens and (2) display the aside properly on small screens (when I set it to "fixed" position, the region_1 content can scroll independently, which is important, but then it doesn't display properly in small screen; if I set it to "static" it displays but doesn't independently scroll)
Hm... We don't have fixed content for a reason... We got a back to top plugin though :wink:
yesterday  tested one hub with this new thing, and  saw that we lost "about this hub (about this hubzilla...)" with all the 3:  /TermsOfService /siteinfo /siteinfo/json .