Zotlabs|Hubzilla Development

Mario Vavti

Fri, 21 Sep 2018 10:35:50 +0000 last edited: Fri, 21 Sep 2018 10:37:44 +0000

Here is the deal:

Every app (a.k.a. module) with settings will have its own settings page accessible either from the app store and from the module UI itself (settings icon beside the app name in the panel).

This will deprecate the additional features and addon settings.

I think this will ease most of the usability issues with settings we have.

If you have any objections, speak now or be quiet forever.

!Hubzilla Development !Hubzilla Support Forum

show all 19 Comments

Steffen K9 🐰

Fri, 21 Sep 2018 17:39:53 +0000 from Friendica

No. From yesterday.

Steffen K9 ?

Fri, 21 Sep 2018 20:49:40 +0000

Pulled again. Ah! Much better.

kris

Sat, 22 Sep 2018 09:48:31 +0000

I agree : exemple the question Start calendar week on Monday could be on the calendar not on channel setting. That will be one less paramater. This is only my last example but you can find a lot like this.

Andhub

Thu, 20 Sep 2018 14:37:53 +0000

Is anyone maintaining an up to date installable version for andhub anywhere? Did a quick search and couldn't find one. I know there was one somewhere because I have it installed! Lol.

!Hubzilla Development !Hubzilla Support Forum

show all 14 Comments

Carlos Solís

Sat, 22 Sep 2018 00:24:18 +0000

Thanks a lot for the link, following now!

sunjam

Sun, 23 Sep 2018 05:27:46 +0000

Hi, please consider sharing a Nomad folder which we can check for the latest versions of the app. This could be done via a Nextcloud shared folder or Hubzilla webdav share afaik. Cheers!

Massimiliano

Sun, 23 Sep 2018 05:46:48 +0000 last edited: Sun, 23 Sep 2018 05:47:17 +0000

@sunjam
I already did share a nextcloud folder.
You can find it joining

https://hub.disroot.org/channel/nomad

Or by nextclod directly

https://cloud.disroot.org/s/p26pCqo7gwMjxMs

Will add files directly on hubzilla as soon as i have spare time.

sunjam

Wed, 19 Sep 2018 15:49:30 +0000

!Hubzilla Development

@funkwhale@mastodon.eliotberriot.com is developing ActivityPub support for sharing audio and video streams, plus allowing Funkwhale users to be followed via ActivityPub. Discussion of integration is in the PixelFed developer Github and Funkwhale Gitlab.

Wed, 19 Sep 2018 20:01:56 +0000

I hope they just use the normal 'Announce' activity which is used for sharing things instead of a new word that isn't in the ActvitivyStreams vocabulary. I've added a note on the funkwhale issue. Will need to double check but if they don't overthink it, everything should just work in Osada.

new Fediverse podcast - PR opportunity?

TLSN.com Admin (Rick)

Tue, 18 Sep 2018 23:42:17 +0000

!Hubzilla Development
I posted elsewhere but THIS is probably the place (I am aka @afterpod admin (rick) ).

a new podcast about the Fediverse hosted by @kevinflo@mastodon.social
https://podDVR.com/?n=95eecc9d-e53b-cdf9-4350-e840b7cb8d91

A knowledgeable person who could LITERALLY SPEAK for Hubzilla could probably get booked for a future episode pretty easily. Probably someone in this forum.

APP Architecture Question

Mon, 17 Sep 2018 19:43:31 +0000

As I see the lay of the land - APPS can be enabled on the server and installed by individual channels, but there is no "middle ground" that allows Apps to be installed on the server and only installable by SOME channels (based on either channel or account restrictions). (maybe I'm missing something... if so, I'd be grateful for a pointer)

I started working on some hooks to make it possible, but ran into an issue looking at the APP synchronization code that causes me to think a solution needs to be more widely discussed.  My work so far simply hides the ability for a user to install an app on on their channel by filtering what is/isn't allowed on the channel app install screen based on a field in the SERVICE_CLASS array.  It is thought to later expand this to a variable in pconfig so that the CART system could be used to allow paid access to specific apps.

I know it needs to go further, but I'm having trouble getting around how to deal with the scenario of a user cloning their channel on another instance and installing/enabling an app on the 2nd instance and having the app synchronization automatically enabling it on the original instance - which - if I read the code correctly - is the likely behavior if the hub itself has the app enabled even if the individual channel doesn't click the "install" button on their channel settings.

Then there's a second issue with regard to hooks.  As far as I can tell, there is no central "app enabled" setting on a per-channel basis that blocks an app's hooks and code from running if it's enabled hub wide even if the app isn't installed on a channel itself (I've run into the scenario of hooks triggering for channels where the app wasn't installed more a couple of times during development).

So far I've resorted to creating an "enable" (pconfig) setting for the app(s) I've created.  Any  hooked functions that are triggered from elsewhere in the system do a check against the pconfig variable to make sure the app is "enabled".  The problem is this solution seems wasteful (every hooked function must run the check every time it's triggered).  And, it doesn't lend itself to the possibility of a hub admin blocking/enabling an app on a per channel or per account basis (for example, from the SERVICE_CLASS settings or even being able to enforce some sort of subscription payment structure for apps) but still having it enabled server wide for use by other users unless the app is specifically coded to behave this way (i.e., the app itself checks SERVICE_CLASS or some setting set by the cart system or some other settable variable).

I admit, I may be entirely missing something obvious in the code - but I don't see the current code permitting these scenarios.  At the same time, I see an implicit intention to support such things.  Even if it is just me reading into the project my own thoughts and desires, it seems that these would certainly be features that would help immensely hub admins who want to more completely "hide" functionality from some users and open it up to more advanced users (or paying subscribers).

There is no "silver bullet" to fix all of these at once.  Any solution will lead to some level of change in the core beyond adding a hook or two or even a few.

Has anyone already thought through a potential solution?  I have some ideas, but I know there are others who know the code better than me.

I think it'd be helpful to have a similar system that allows the locking of certain features generally and default settings on an account (or preferably, both an account and a per-channel) basis - though, until we get to the end of the "appification" process, I think that should wait.

show all 6 Comments

Mon, 17 Sep 2018 20:43:25 +0000

Basically I think you're going about it wrong. An app is just a link. Nothing more. We don't try to protect the app. We protect the link. Paying for an app puts you in the ACL for the link. Anybody can copy and share the app. There are some access controls on the apps themselves so we only show them when installed and appropriate (there are checks available to enable the app only to logged in channels for instance as well as checking that a required plugin is installed). It would be easy to check service class restrictions with the caveat that there is no convention on service class names so you would probably have to check the actual limits you are interested in rather than rely on a particular service class name.

Mon, 17 Sep 2018 21:20:44 +0000 last edited: Mon, 17 Sep 2018 21:55:44 +0000

Based on your description, I see what you're getting at (I think) --- "apps" as "links" which may or may not reside on the local hub. I grok'd this at one point, but lost it between then and now somehow.

What I really meant was "addon"/"plugin" (as in hub-local discrete PHP unit that performs some desired function) not "app." (a pointer/link to a local or remote sub-application that performs a desired function).

So if you rewind what I said above and replace "app" in the OP with "addon" it's more correct.... I think.

What I'm looking for is a standardized way to enable/disable the running code related to individual addons on a per account/per channel basis without the need to code each individual addon with it's own service_class / pconfig / cart "enablement verification subroutines". I can imagine there will likely be some other ways that people will invent in the future to check whether or not a given addon should run for a given account/channel (like check some sort of verification token against a block chain licensing system). I'd like the decision as to whether or not it runs for a specific user to be determined and be configurable by the hub-admin and not determined by the plugin author.

As I see it, it would require some sort of checking of HOOKS to see if they should run (perhaps adding an "addon" field, or maybe just checking against the filename of the hook) - as well as some method to know if it should be considered a "linkable app" or not.

Or am I still thinking about something incorrectly?

Mon, 17 Sep 2018 23:09:38 +0000

I understand what you're getting at, but getting there from here is probably a bit of work and will need to be added to each addon. The problem (as you've correctly surmised) is hooks. Hooks run at the system level and don't know who is calling them. In order to (for instance) disable Diaspora functionality to anybody that didn't have the Diaspora protocol enabled, we needed to do the check inside many of the hook functions. Complicating this is the fact that some hooks run under "daemon" context and are acting on behalf of somebody, but there is no identity in the system we can use to figure out who that is. We need the information provided in the hook to determine who precisely is the person of interest.

Tue, 18 Sep 2018 01:04:48 +0000

At the hook level itself, we simply need a binary "yes/no" do or don't run this hook, right? So what about the following in call_hooks() right at the beginning of the foreach loop:

$checkhook = [
        'name'=>$name,
        'hook'=>$hook,
        'permit'=>true
        ]
if ($name != 'permit_hook') {  // avoid looping
        call_hooks('permit_hook',$checkhook);
        if (!$checkhook['permit']) {
                continue;
        }
}

I'm not sure the copy needed to include $data would be worth it - unless it's still true that variable copies aren't actually created until modification (cxref: http://php.net/manual/en/language.references.php#41114 ), in which case it's a no-brainer that you'd want to add it.

Then, from a "core" vantage point, how someone wants to implement hook permissions is out of our hands. For some addon's (probably the great majority of 3rd party developed apps), it would be an easy check because the needed state (channel references, observer references, etc) will be known before the hook gets triggered - If you want to exclude an addon wholesale, just check the filename of the hook:

if (strpos($checkhook['hook'][0],"addon/{$addonslug}/")) { 
        if ( {{ CUSTOM HOOK LOGIC }} ) {
                $checkhook['permit']=false; 
        }
}

return;

This won't catch hooks added by hook_insert(). But a similar if statement could be made to check the function name ( $checkhook['hook'][1] ) against a list of hooks (or class names) you want to exclude.

Of course, the majority of 3rd party addons can probably be handled using the module_loaded hook in \Zotlabs\Web\Router::__construct().

Users of these hooks would need to know the details of the modules they want to filter out - but that would be "their problem" to figure out.

Am I missing something?

Tue, 18 Sep 2018 02:01:00 +0000

That's fine if you just want to allow or prevent a hook. I was only mentioning that there isn't a lot of context. I don't know how you could allow the hook for one person (say due to their service class) and deny it to another per this statement(*) because the hooks themselves don't know who is accessing them.

(*)

What I'm looking for is a standardized way to enable/disable the running code related to individual addons on a per account/per channel basis

You may be able to get away with session information (local_channel(), remote_channel()) but this will only be applicable to a very small number of hooks which are invoked via web access. If you're ok with that limitation, fine.

Tue, 18 Sep 2018 02:26:10 +0000

Ah, I see what you're concern is. THAT is the ideal. Clearly we aren't there at this point - so a method customized by addon is the best I think we can do. I think the proposed solution provides the flexibility to facilitate a standardized solution in the future - while making the aim and goal possible (if a bit arduous) in the short term.

As for context on addons that need to at least BEGIN running before there is enough context to make a determination, I think this solution allows someone to build a traffic director that could gather that context as it goes. Of course, you'd have to study the hooks and the data structures for the plugin(s) you want to allow/prohibit and you'd only be able to make a determination after the hooks that build the context needed have triggered (basically you'd need to whitelist some hooks and then blacklist others if needed after you had enough info to do so). But I think this provides the flexibility to do so without admins needing to adjust the addons themselves.

And, with the structure there and the aims and goals in the open, maybe addon authors in the community would consider structuring their addons in a way that makes needed criteria easily available in a standardized way in the future.

sunjam

Mon, 17 Sep 2018 19:09:05 +0000 last edited: Mon, 17 Sep 2018 20:01:37 +0000

!Hubzilla Development
cc at !Zot universe NEWS

Socialhome project is interested in adopting the Zot protocol as mentioned here on their Gitlab or discussed on the Github mirror here. Looks like they will be exploring it once ActivityPub support is completed.

poVoq

Tue, 18 Sep 2018 15:26:01 +0000

If you added Zot support to your federation library, this would allow any app using Python/ Django (eg GetTogether) to also add Zot support, by using (and hopefully contributing to) your federation library.

That would be awesome! Lots of interesting Django apps around.

sunjam

Wed, 28 Nov 2018 23:56:18 +0000

Project issue is still alive on Gitlab. https://git.feneas.org/socialhome/socialhome

hEARt PhoniX

Thu, 29 Nov 2018 00:03:24 +0000

Correct, the github for the library is 404. I'd believe it might have moved.
This does sound quite encouraging.

At least we can state that Zot is being seen and considered.

Thanks for opening the issue! There is actually an issue open in the federation library for Zot support, so further discussion could continue there.

Mario Vavti

Sat, 15 Sep 2018 15:13:04 +0000

!Hubzilla Development !Hubzilla Support Forum

Libranet Support wrote the following post Sat, 15 Sep 2018 11:46:20 +0000

Hubzilla - carddav and caldav update

Hello Hubzilla users on hub.libranet.de,
there was an update to the 'cdav' stuff ? It has been "appified".

WARNING: if you use caldav or carddav from a client or the webinterface you will need to enable those apps to make things work again

#hubzilla #caldav #carddav

Cart Addon - Request for Testers & Feedback

Fri, 14 Sep 2018 15:45:55 +0000

!Hubzilla Cart Addon !Hubzilla Development !Hubzilla Support Forum

@Mario Vavti mentioned that we can hopefully expect 3.8RC to come the end of this month. I'd at least like to make sure by then that all the existing functionality of the cart system is working correctly. I've pushed a few UI tweaks in the last week or so. But I haven't heard any real feedback. If you are running the DEV branch of Hubzilla on a server and could do some testing, it'd be greatly appreciated. I'm going to try to get some docs of how to do some things put together soon as well, but I'd kind of like to know what people can/can't figure out on their own.

So any feedback would be helpful. I'm going to be honest - I'm not a UI guy. Any GOOD UI elements are probably Mario's doing trying to make things look better (THANKS MARIO!).

What SHOULD be working:

1) The TEST catalog
2) Manual catalog items (as if you were going to take orders on line but do all the back end processing manually)
3) Hubzilla Services (add buyer as connection, add buyer to privacy group, and for hub admins, change service_class of buyer's account)
4) Subscriptions (extend length of subscription on subsequent purchase, auto expiration and "rollback" of Services if using the Hubzilla Services module)
5) Paypal payments
6) Auto-fulfillment upon Paypal payment
7) Manual payments
8) "My Shop" admin tools to fulfill and take notes about an order.
9) "Shopping cart" functionality
10) Order button widget for use in web pages and other areas where widgets are enabled.

Hubzilla API Questions

Lasantha Ranaweera

Fri, 14 Sep 2018 05:21:12 +0000

!Hubzilla Development
First of all thanks everybody who are contributing in this wonderful project.

We are using Hubzilla to build enterprise educational application. Hubzilla acts as underline engine to provide social networking features in the enterprise application mentioned. Our web application use REST api provided by Hubzilla for the communication. We have some questions on Hubzilla API and hope some of you may point in to correct path.

1. API to create account, profile and users in Hubzilla ?
2. API to create or update profile pictures of a channel ?

show all 5 Comments

Harald Eilertsen

Fri, 14 Sep 2018 08:00:57 +0000

If the documentation is anything to go by, there doesn't seem to be support for that in the APIs yet. You can upload an image using the item/update endpoint, but I don't see any documented way of assigning it as a profile picture of the channel.

Waitman Gobble

Fri, 14 Sep 2018 10:27:36 +0000

i have a php example that does that. its probably on my feed somewhere... or I can look for it in awhile.

Lasantha Ranaweera

Fri, 14 Sep 2018 10:43:49 +0000

Thanks.

I guess you are talking about

https://hub.zilla.tech/display/fe2d72cd31e56268547029f552b2d8f1973202962231db99e1cfbf4183b2a63f@hub.zilla.tech

Anmol Sharma

Fri, 14 Sep 2018 16:20:46 +0000

:bravo

poVoq

Fri, 14 Sep 2018 17:42:36 +0000

1. API to create account, profile and users in Hubzilla ?

You could do that through the LDAP auth plugin. Not that easy to setup, but the LDAP ecosystem would open many ways to automate user-creation.

Arbitrary Object Storage for Addons

Thu, 13 Sep 2018 16:33:23 +0000

The goals:
  * Maintain current security regarding content restrictions and content filtering in existing apps/modules.
  * Maintain/allow privacy settings and restrictions on stored items of existing modules/apps.
  * Allow addon devs to store and retrieve arbitrary unfiltered data for use by their addon.
  * Allow arbitrary unfiltered data to be assigned privacy settings and restrictions consistent with other modules/apps.
  * Provide a mechanism for unfiltered addon data to be cloned to channel clones. (Nomadic identity remains in tact even if the addon is not installed and running on the clone's hub - the data will not be used without the addon (unless it's accessible through the cloud/file interface), but it will exist in the even that the addon is installed and activated in the future).

Proposed solution:
  * A standardized interface for addons to track/access and save and retrieve data in the existing attachment file store as an arbitrary data store.

Implementation suggestion:
  * add an "attconfig" table (k/v store) and utilities for items in the attach table that mirrors pconfig, iconfig, abconfig, etc. for storage and search of addon-specific attributes.
  * add an "addon" column to the attach table to track the originating addon
  * implement an interface for the content column (insert/update) (attach.os_storage = 0) to store arbitrary data in the database
  * implement an interface for os file contents (attach.os_storage = 1) for addons that may want to allow WebDAV file based updates to app data.

show all 5 Comments

Thu, 13 Sep 2018 19:22:36 +0000

(As usual, the "suggestion" is not necessarily for somebody else to do - but it is the way I think it should be implemented. If somebody else WANTS to tackle it - I'm sure they're a better coder than me anyway - so they can have at it... But this is more or less a note to invite feedback on my plan of attack)

Einer von Vielen

Thu, 13 Sep 2018 20:39:36 +0000 last edited: Thu, 13 Sep 2018 20:49:14 +0000

Thats interesting. My addon flashcards could probably use it. Atm I am able to use it and learn Italian. Next step will be to use the ACL in order to share the box (of flashcards).

There I have an additional problem to solve...

A box of flashcards has n cards. Each card contains two languages, an id, time stamp last changed. Every user can create own boxes and share them with other users and allow every user to edit a card and re-share it. Ok, I will use the ACL stuff for this. How to merge the content of the box? My idea is to copy the whole box with all cards for every user. When a box is shared the addon compares the time stamp of every card to decide what content will win. I have this still in place if if I share my own single box German-Italian. Because the field "obj" (of type "text") in table "item" is to small to store a box as JSON with many cards (my has 1400 cards) I store only the "meta data" of the box there and use the field "v" (of type "mediumtext") of table "iconfig". This is pretty easy by the way by using the function set_iconfig(....) and later on get the all the cards for a box by using the function get_iconfig(...). As far as I remember from debugging the code @Mike Macgirvin has also implemented automatic cloning for both of the table items in "item" and "iconfig". I did not test and investigate yet.
When merging boxes from different users I take care of the private part of every card - the learn progress. This of course is not shared between different users.

Btw...
Thanks for the hint that there is problem when using a box box with clones but not every Hub has necessarily installed the addon.

Sorry for talking about my own stuff so long. I just wanted you to know that someone is interested in your ideas and why. And there could be some chance that I could use it. The addon itself seems not to be an a state where I would dare to let others use is.

/update/ corrected some spelling

Thu, 13 Sep 2018 21:00:28 +0000 last edited: Thu, 13 Sep 2018 21:16:01 +0000

From my remberance of the code, both item and item_id are cloned, you are correct.

No apology needed for talking about your project... It's great to hear how others are using the platform! It's good for ideas and it's good for the devs to know others are making use of what they have created!

Einer von Vielen

Fri, 14 Sep 2018 11:23:14 +0000

It's good for ideas and it's good for the devs to know others are making use of what they have created!

I do not much comment usually but read the dev and support forum like a newspaper every day. It is very interesting to follow the thoughts. It helps me to understand better whats going on under the hood of Hubzilla

Sat, 15 Sep 2018 16:17:21 +0000

Investigating and thinking through implementation....

I'd rather not muck around with the core. Creating AttConfig appears it will be a nightmare - and I don't think sending whole file updates with every meta data change is reasonable. Now I'm thinking of a completely different implementation - but with the same result - feedback would be appreciated.

Instead of using a new "config" table for meta data and needing to build a new synchronization structure, what about using the current pconfig to store file metadata for the files?

I'm thinking: structure the 'category' something like appfile:{appslug}:{attachmenthash}. Then the app can have full control over the 'key' and 'value'. This has the benefit that PCONFIG is already nomadic aware. And updates to meta data will not trigger the added network traffic of a file synchronization.

The only complication I can see is the possibility of file deletion while leaving meta data. But I think a hook in the attach_delete() function could easily remedy that.

This means no core coding (except for the additional hook), and should still permit an implementation of the intention of arbitrary object/file storage for apps.

Thoughts?

Zotlabs|Hubzilla Development

hubzilla-development@zotlabs.org