last edited: Mon, 24 Sep 2018 15:44:29 -0400  
!Hubzilla Development !Hubzilla Support Forum

A little tip to make tracing what's going on with users perhaps just a little easier - or, if you're like me and have several browser windows open, it becomes difficult to trace what each one's doing and can be quite confusing. This also irreversably obfuscates potential identity information and may be handy for GDPR compliance.

1) Change your MAIN logging string to use a custom MD5 hash (this usually resides in nginx.conf:


log_format main '$remote_digest - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';


2) Set the $remote_digest variable in your server configuration


set $mkdigest '{SomeCustomSalt} $remote_addr $cookie_PHPSESSID';
set_md5 $remote_digest '$mkdigest';


3) Apply the main logging string to your logs


access_log /var/log/host-access.log main;


You can create a similar string for the error logging.

You will not be able to identify IP addresses anymore, but this will actually be MORE HELPFUL in looking at your logs. Imagine a family all sitting behind a NAT router in their home. There would be no way in the log to identify which is which! But with this, each device even on a NAT network has it's own tag - allowing you to [strike]track them independently of[/strike] [underline]distinguish them from[underline] one another.
  
You can usually identify the remote channel, as it's provided as a string in the url.
That way you can often link the hash with a channel and a channel is a login.

Yes, "default" logs are bad. You add additional logging, as you include a random number to identify multiple people using the same IP. Even if you don't directly log that IP, your logging is more specific than an IP, thus you increase the tracking above the default levels.
  
You can usually identify the remote channel, as it's provided as a string in the url.
That way you can often link the hash with a channel and a channel is a login.


Removing arguments from the log and logging only the URL itself (not the additional query string data) mitigates that issue (and is the one I was referencing as the potential to infer).

It seems your caught up on the fact that I used the specific term "track," which was a loose way of speaking and described the action of following a specific session which, though is tied to an individual, is not directly identifiable with the "data subject." I agree that some level of further mitigation is necessary in order to pseudononymize the data for full compliance, thus why my specific statement was, "may be handy (i.e., helpful) for GDPR compliance". This wasn't presented as a "silver bullet" or a full solution, it was presented as a helpful tip and a pointer in the right direction.
  
Of course, if you want to be fully compliant, you simply won't run a web server that others access and you'll rely on the big data brokers like Facebook, Google and others who openly admit they mine your data and force you to accept that fact or go without their services. That's an option also.

  
newtest
  
(oops... sorry for the spam... Thought I had things set to not do that... DOH!)

  
test
  
  
pop quiz. Which BBC music programme was broadcast weekly between 1964 and 2006?


  
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
  
Thanks a lot for the link, following now!
  
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!
  
@sunjam
I already did share a nextcloud folder.
Jou 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. ;-)

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

  last edited: Sat, 15 Sep 2018 12:25:57 -0400  
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.

NEW Implementation suggestion: (Updated 9/15/2018)
* Store file metadata in pconfig with a structured category appfile:{appslug}:{filehash}
* Create an interface to interact with the existing file storage functions - or - possibly even leave it to addon devs to interact with the storage functions as it shouldn't really be that complicated at that point.
  last edited: Thu, 13 Sep 2018 17:16:01 -0400  
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!
  
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
  
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?

  
M. DentM. Dent wrote the following post Thu, 13 Sep 2018 00:33:03 -0400
Withdrawl of PR 1270 (various Hooks)
https://framagit.org/hubzilla/core/merge_requests/1270

Just a note withdrawing PR 1270 - some notes are in the PR discussion itself.

1) Hook to change App::$page just prior to page display -- after consideration, I'm not sure at all what this adds. At any rate, whatever the reasoning I had for submitting it originally no longer obtains. If someone else thinks it's a good idea, I guess it could be resubmitted.

2) Hook into Articles - It looks like the better solution is for any addon dev who wants to make changes to the articles module is to clone the articles module and just make the changes. The call to status_editor() adds data to App::$page['htmlhead'], and could mess up settings if the jot editor is going to be used. To fix that would require a second hook to change the behavior of status_editor(). And by that point, any dev would be recreating significant portions of the current module anyway and may as well just go that route. It's not that big/scary or complicated. So either an addon on it's own endpoint - or even using the facility for Zotlabs/SiteModules/Articles.php (see Zotlabs/Web/Router.php) is probably the correct solution.

3) HTMLPurifier - It was a first stab to lessen restrictions in certain cases for articles, web pages, wiki entries, maybe cards while still allowing the use of nomadic identity and automatic cloning of those items. Digging more deeply, it's clear that the the way things are transmitted (see include/zot.php::process_delivery()) means that any modificatons to HTMLPurify configuration would need to be universal (all item types) and site-wide (actually ALSO be implemented on all sites where channel clones reside) in order to work. So now I see the overall concern with changing it as proposed - to work, it would not only have loosened restrictions for the desired item types on the local machine, it would have needed to be a univeral loosening of restrictions. In that way, I agree. Bad idea.

I have an different approach/alternative that I'd like to float - but I want to sleep on it and see if any gotcha's come to the fore in the morning.

Anyway - thanks @Mike Macgirvin and @Mario Vavti for your patience... you have a much better handle on the code base than I do. I trust you both enough to know that when you give resistance to an idea, there are reasons - even if they aren't readily apparent. I imagine sometimes for you there isn't more than an initial "gut feeling" that it's a bad idea - but it would take you quite a bit of digging back through to figure out exactly why - which isn't a reasonable expectation for others to impose on you. At any rate, I wanted to put these notes here - mostly for explanation, posterity, and as an apology if I came off a bit pushy.


Meant to share this to the forums:
!Hubzilla Development !Hubzilla Support Forum
  
IIRC you can add forum mentions also in edits...
  
Thanks.. Wasn't sure and it was getting super late.

  
https://framagit.org/hubzilla/core/merge_requests/1270

Just a note withdrawing PR 1270 - some notes are in the PR discussion itself.

1) Hook to change App::$page just prior to page display -- after consideration, I'm not sure at all what this adds. At any rate, whatever the reasoning I had for submitting it originally no longer obtains. If someone else thinks it's a good idea, I guess it could be resubmitted.

2) Hook into Articles - It looks like the better solution is for any addon dev who wants to make changes to the articles module is to clone the articles module and just make the changes. The call to status_editor() adds data to App::$page['htmlhead'], and could mess up settings if the jot editor is going to be used. To fix that would require a second hook to change the behavior of status_editor(). And by that point, any dev would be recreating significant portions of the current module anyway and may as well just go that route. It's not that big/scary or complicated. So either an addon on it's own endpoint - or even using the facility for Zotlabs/SiteModules/Articles.php (see Zotlabs/Web/Router.php) is probably the correct solution.

3) HTMLPurifier - It was a first stab to lessen restrictions in certain cases for articles, web pages, wiki entries, maybe cards while still allowing the use of nomadic identity and automatic cloning of those items. Digging more deeply, it's clear that the the way things are transmitted (see include/zot.php::process_delivery()) means that any modificatons to HTMLPurify configuration would need to be universal (all item types) and site-wide (actually ALSO be implemented on all sites where channel clones reside) in order to work. So now I see the overall concern with changing it as proposed - to work, it would not only have loosened restrictions for the desired item types on the local machine, it would have needed to be a univeral loosening of restrictions. In that way, I agree. Bad idea.

I have an different approach/alternative that I'd like to float - but I want to sleep on it and see if any gotcha's come to the fore in the morning.

Anyway - thanks @Mike Macgirvin and @Mario Vavti for your patience... you have a much better handle on the code base than I do. I trust you both enough to know that when you give resistance to an idea, there are reasons - even if they aren't readily apparent. I imagine sometimes for you there isn't more than an initial "gut feeling" that it's a bad idea - but it would take you quite a bit of digging back through to figure out exactly why - which isn't a reasonable expectation for others to impose on you. At any rate, I wanted to put these notes here - mostly for explanation, posterity, and as an apology if I came off a bit pushy.
  
No need to apology. It was certainly a "gut feeling" for me. Allthough i am not opposed to have those hooks (you certainly have a point with "anyone can fork and do his own thing anyway"), i think it needs a broader discussion.
  
Ultimately, the only hook of the list worth considering, IMHO, is the HTMLPurifier hook. And the way that items are filtered during distribution and the fact that you can't assume that all the hubs involved (even of cloned channels) will have the addons installed, an addon that hooks in and changes the HTMLPurifier settings will have it's data munged when it gets passed on to other hubs (even cloned) - at least that's what I see in the code. That being the case, the data transmission will be unreliable and introduce major headaches for addon devs and/or hub admins and/or users. So I don't see that as even a reasonable solution. I just hadn't dug through ALL the ramifications with regard to transmission and only considered the local hub as I was making the proposal.

A better solution, I think, is a nomadic aware arbitrary storage solution for addons (see proposal in the Dev forum. MOST of the needed things are already there (or exist in other parts of the infrastructure). So I've redirected consideration to that solution at this point.

  
From SLASHDOT:

Worries Arise About Security of New WebAuthn Protocol - Slashdot

Image/photo

An anonymous reader writes: "A team of security researchers has raised the alarm about some cryptography-related issues with the newly released WebAuthn passwordless authentication protocol," reports ZDNet. "The new WebAuthn protocol will allow users of a device -- such as a computer or a smartphone -- to authenticate on a website using a USB security key, a biometric solution, or his computer or smartphone's password." But researchers say that because WebAuthn uses weak algorithms for the operations of registering a new device, they can pull off some attacks against it.


!Hubzilla Development
  
I love this quote:

PKCS1v1.5 is bad. The exploits are almost old enough to legally drink alcohol in the United States
  
That article reminds me... I followed up on some of the discussion from that summit with one of the panelists who sounded all excited to help out and offer advice to DWeb projects... My question was fairly simple, "you and fellow panelists offered help... how do we initiate a discussion?" I never received any sort of repy. Did someone from the project do something to tick off the EFF or Cindy Cohn specifically?
  
I didn't find the word 'Hubzilla' in that text
  
Hubzilla = Redmatrix - the project was renamed in 2015.

Here's a great history of Hubzilla: http://www.talkplus.org/blog/2016/the-history-of-hubzilla/

  
!Hubzilla Development

The Channel Reputation Addon is intended to track the reputation of those who comment/post on a channel. When the poster/commenter's reputation is too low, posting and commenting is automatically disabled until the reputation improves. Reputation automatically improves slowly over time. Each post and each comment "costs" a small amount of reputation as well. (AUTHORS are able to comment on their own posts no matter *[see note below] - but will still have their reputation points reduced for their comments).

In the initial commit, the automated tracking and scoring works. A forthcoming update should complete the ability for those with enough reputation to act as moderators and use their reputation points to increase/decrease the reputation of another poster/commenter on the page.

This is most useful for a public/semi-public or private forum to allow the community to work together to police community standards.

Future updates will include the ability to designate specific "moderators" as well who will be able to increase/decrease the reputation of other members of the community up to a certain value without losing any of their own reputation points. Otherwise, for normal community moderation, the person moderating will lose points in order to increase/decrease another participants reputation score.

Reputation score is recalculated on each page visit or each attempt to remotely post/comment.

The current default settings were arbitrarily assigned as a "best guess" beginning point and can be changed in the addon's settings:

'starting_reputation' => 3, //Reputation automatically given to new members
'minimum_reputation' => -2, //Reputation will never fall below this value
'minimum_to_post' => 2, //Minimum reputation before posting is allowed
'minimum_to_comment' => 1, //Minimum reputation before commenting is allowed
'minimum_to_moderate' => 4, //Minimum reputation before a member is able to moderate other posts
'max_moderation_factor' => 0.25, //max ratio of moderator's reputation that can be added to/deducted from reputation of person being moderated
'post_cost' => 2, //Reputation "cost" to post
'comment_cost' => 1, //Reputation "cost" to comment
'hourly_post_recovery' => 0.25, //Reputation automatically recovers at this rate per hour until it reaches minimum_to_post
'hourly_moderate_recovery' => 0.125, //When minimum_to_moderate > reputation > minimum_to_post reputation recovers at this rate per hour
'moderators_groups' => Array('Moderators'), //Members of these groups do not lose reputation by moderating (up to moderators_modpoints) NOT IMPLEMENTED
'moderators_modpoints' => 2, //Members of moderators_groups may reward/penalize up to this amount per moderation action without losing any of their personal reputation
'moderate_by' => CHANNELREPUTATION_COMMUNITYMODERATION

*[NOTE ABOUT AUTHOR COMMENTS: A bug in CORE versions <= 3.6.1 may prevent this in some circumstances. A patch has been submitted as of this writing and is awaiting validation and integration. cxref: https://framagit.org/hubzilla/core/merge_requests/1268 ]

  last edited: Sat, 01 Sep 2018 00:28:45 -0400  
!Hubzilla Development

Zotlabs\Lib\Threadstream::add_thread() always permits comments by the thread author if comments are not disabled. But perm_is_allowed() and the perm_is_allowed hook which is called to validate permission when the comment is submitted has no mechanism to determine if the item being commented on is owned by the commenter.

The result is, if the thread is [strike]owned[/strike] [underline]authored[/underline] by the observer, the comment box with the submit button is displayed, but if perm_is_allowed() denies commenting, the comment is denied. I understand the desire to want to allow a thread author to always comment and that it would be a fairly rare occurrence where it may be disabled. In a forum or a community, a thread owner's commenting permissions may be revoked after they post a thread, so it's conceivable that the circumstance may arise. However given the inconsistency, I'm not sure the best way to handle it. I'm personally tempted to say, "perms are perms and if you don't have perms to comment on the page/thread to comment, then you don't have permission."

I guess my question ends up.... Is there any circumstance or configuration currently where someone may be relying upon this behavior? Or can we remove the permission for a thread owner to always be able to comment on their thread when it appears on another channel's wall?
  
@Mario Vavti Resubmitted corrected version.

Well played @Mike Macgirvin , well played!
 
is that authors should always be allowed to comment on their own authored posts, even on forums where the forum channel is the "owner" of the post.


I don't think I got this right. So if I remove permission from someone on a forum - let's say, cause they're no longer on the team or because of their behavior - they can still post to the forum in the form of comments on their own previous posts? This makes sense?
  
That is the "expected behavior" of the software.. It DOES make some sense when you consider federation and the desire to keep all instances of the discussion thread synchronized considering federation and the possibility of ! mentions.

I completely understand and agree with a forum owner's desire to exert control and that produces its own set of issues. ! mentions end up the biggest issue. But the ability for an author to comment on his own thread after removal has actually always been there through the forum wall. Ultimately we simply need to be consistent.

If you need that level of control, turn off ! mentions and if you remove a member remove their threads. There may be other solutions that can be implemented, but those are available now.

  
@test private forum

A test mention to my private forum
  
I don't think you fully grok private forums. We only allow them to posted via wall-to-wall to prevent message leakage to anybody who is not a forum member.  They do not have mention tag posting enabled. Also to post to a forum use ! instead of @ , unless you're trying your own hack to get around the privacy settings somehow.
  
Lol... oops... nope, no attempted privacy setting avoidance - more like fat fingering and forgetting the tags.  Though, having a private forum show up in the select list is probably something  that shouldn't happen.

But thanks for the note... it explains why my logging was unexpectedly going nuts, LOL.

  
!Hubzilla Development

As far as I can tell, there haven't been a lot of developers using the many many hooks with in Hubzilla to alter it's behavior. Coming from developing in WordPress, I love all the hooks!

I was looking at the include/plugin.php call_hooks() function, however, and remembered something I ran across a long time ago - array_key_exists is slow.

Is there any reason not to change

if((is_array(App::$hooks)) && (array_key_exists($name, App::$hooks))) { ... }

to

if (isset(App::$hooks[$name])) { ... }

???

The key thing to know about isset is that it checks both whether the variable (or array element) exists AND that it is NOT null. Since call_hooks launches right into a foreach loop using App::$hooks[$name], I don't see any problem with the substitution.

Yes, it's a micro-optimzation, and with only about 450 call_hooks in the codebase (by a very quick grep|wc), it may not be a huge boost, I know for a fact, some of those calls are in loops and may run a number of times each - in which case every little bit helps! It also would reduce the twinge I feel every time I look at the code and say, "You know, it'd be really nice if I could tweak this or that with an addon just before this next section of code runs".
  
From everything I read yesterday, the only thing that won't be caught withisset() is if the array element's value is null. I think the best test for that condition would be (isset($arr[$x]) && $arr[$x] !== null) (untested). If isset() fails it won't proceed to the comparison. The other caveat is to make sure it is arrays and not objects that get tested - it will choke on objects.
  
As to the multiple hooks, I thought there was a check. I know I had a problem at one point with hooks not getting saved/triggered if two references had the same priority. THAT is annoying, but rather than looking, I just compensated by making sure I didn't duplicate priorities at this point. Sounds like the opposite problem.

I can see a race developing from Cron or elsewhwere doing an unload/reload at the same time as someone doing it manually. We reload often enough that a busy site may even have multiple threads running at the same time.

One option off the top of my head would be to set a config variable with a timestamp at the beginning of any unload/reload.

Before doing an unload/reload make sure that either 3 seconds (or however long we think is reasonable) has elapsed or that the timestamp does not exist. As to the time, we could have a "last reload took x" config variable and add a small buffer if we really wanted to try to optimize it.
  
This is a query to find potential duplicates:
SELECT
    hook, file, fn, COUNT(*)
FROM
    hook
GROUP BY
    hook, file, fn
HAVING
    COUNT(*) > 1

Just found some duplicate hooks for the pubcrawl plugin astonished face
Disable and enable the plugin fixed it...

  
!Hubzilla Development

I'm trying to track down the flow for comments posted to forum items (initial posts as well, but for now, comments). From some testing, it appears that if a person who comments to a forum item from a feed on their own hub, the comment is inserted into the item table locally and a copy is sent to the appropriate list taken from the parent rather than the comment just being shipped off and being inserted into items when it is received from the forum itself. Am I correct?

I determined this from an analysis of the logs when commenting on an item.

Is this behavior intended?
  
Is the best way to remove items from the list to do an explode/array_diff/implode?
  
yes
  
Just a test comment - having some queue weirdness on my main hub.

  
!Hubzilla Development

I found myself thinking about moderation, community building and ratings systems as I'm waiting for my wife to have surgery this morning.

My usecase for Hubzilla is specifically in the area of fostering communities rather than the "free-for-all" that dominates the "social media" space. I've found that there is a desperate need to work together in community to get things done, and that the social media outlets, while great at generating a lot of noise, often do not foster a way to actually move the ball forward and get things done as the best and brightest within the community are usually so taken up with moderation tasks and "herding cats" that there is little time to actually advance the cause.

At the same time, "social media" aspects are important and a somewhat open arena for ideas is desirable - unless and until it impedes the ability to actually make progress and have reasonable discussions.

I know that the global reputation system is "being reworked" - but in all honesty, I'm not so certain what the benefits are to a global reputation system for content - perhaps some sort of reputation that would confirm identity or the reliability of facts about an identity - but that doesn't translate to the benefit or merit of a specific identity within the context of a specific group or community.

In the offline world, very very few people have any "global reputation" to speak of. We can talk all we want about the internet "democratizing" speech and access, but let's be honest, "reputation" is not really something that's universal and it doesn't transfer unmediated beyond the relationship(s) of individuals or community. Even in a community, each individual keeps a reputation score that tracks their perception of the reputation of another actor within the social system. Within groups, at individual judgment tends to developed into a shared "reputation" that creates a social hierarchy.

Beyond the lack of nuance in a "global reputation," most reputation systems create a single score for something that has at least two aspects (probably more). For example, a reputation system based on "like"/"dislike" of a comment or post doesn't take into consideration that I may like or appreciate THAT the statement was made while at the same time, I may dislike the need or conclusion that the comment leads to. SO there is an "insight" aspect (how useful/insightful/perceptive the comment is), as well as a "content" aspect. A third consideration is just the mere "stake" or "presence" in a community - the passive participation that happens by being involved in a community (eg, reading posts even if you don't respond) should also count for something.

In collaborative communities, it would seem that "insight" is more important than "content." But even that depends on the type of community. Take for instance a community of journalists providing a common shared space for joint efforts at reporting. In this sort of instance, the quality/reliability of the content outweighs the insightfulness of any editorial considerations.

But in most cases, I think these two metrics provide a fairly robust framework for guaging the reputation of a participant - and "presence" provides a bit of a mediating effect - that can be used to lessen the effects of negative feedback. There's always that wise guy in the corner who rarely speaks, but because they think deeply and rarely say something stupid, when they do speak up their opinion is all the more respected. There's also that person who becomes more wise and prudent after being chastised by the community for bad behavior and after a "time out" becomes a meaningful contributor.

With all of this in mind, I'm wondering if we don't want to flip the whole "reputation" idea on its head and develop a composite reputation system based on these various factors and instead of having some sort of global reputation, assign each identity a reputation in relationship to other identities and build a mechanism to take into consideration the three factors of content quality, insight, and "stake" (long term presence).

I'm not sure how to do it from a UI perspective - but from a reputation scoring standpoint and the "effects" of reputation, I would propose something like the following: (The example case considers a public "forum" in Hubzilla with proposed reputation scoring turned on)

1) Members below a certain reputation threshhold are "muted" (unable to comment and/or post - possibly with separate threshholds for posting/commenting - and possibly with separate threshholds for insight/content - configurable by the channel owner/administrator). I'm imagining that the channel will also have a "whitelist" and/or the ability to manually set/override the reputation of a given participant.
2) Each comment/post is able to be rated separately based on insight and content. It might be advisable to include ratings in the calculation for a specified period of time to avoid manipulation by rating previous posts/comments.
3) Ratings increase/decrease the reputation of a participant within the group in proportion to the "rank" of the rater within the community. For each content/insight
Member Community Rating = Member Community Rating +|- (rater reputation / total rater reputation "voting" on post.
4) Each community member whose rating is below the post/comment threshhold has their rating increased by a configurable value over time to allow them an opportunity to re-enter as a contributing member of the community.

VARIATIONS:
- It may be desirable to also have a POST COMMUNITY RATING that would exclude posts from at least the community stream / wall or only show the headline if the post's rating falls below a certain threshhold.
- It may be desirable to allow the channel owner to create a fixed list of raters and only have those ratings count
- It may be desirable to set a floor to how low a rating can go - likewise, it may be desirable to set a ceiling - at least for the effective "stake" (i.e., how much a given rater's vote contributes to another person's rating)
- It may be desirable to set a "initial value" for new members of the community - if additional complexity is desired, it could be based on some sort of "endorsement" by other members of the community.
- It may be an added bonus if there were a way for one community to somehow find out the reputation of a member of other related communities and take that into consideration in the calculation as well - maybe a "pooled" reputation scheme/mechanism - or some sort of "subscribe to reputation changes on this channel" system with an analogous, "share reputation information" setting.

As usual - these are thoughts for consideration - not a demand for implementation. Just looking for feedback and ideas from others that may guide an implementation if I decide to do it and looking to give others ideas if they wish to pursue it themselves.
  
Thanks - surgery was planned - a computer nerd married to a teacher - I'm guessing it was round #1 of 4 for carpal tunnel surgery. Her #2 is set for December. Guessing mine will get to the point where I'll need to do something next year (probably sooner if I meet all my development goals for this year, LOL)

Thanks for the pointer to Discourse. I'll have to take a closer look.
  
carpal tunnel blows. i get it from typing. but i switched to ms natural split keyboard years ago and it's really helped. if they ever stop making those i'm going to buy up a bunch of them. They tend to wear out, the ink starts coming off the keys after about a year and about 5 years the keys are all blank. I don't have to see the keys but it's nice sometimes. lol. This one i have here is about a year old and the S is gone.

anyway,

i kind of think the trust thing is maybe like going to a book store? If you buy unknown authors based on editor comments they put on the books. Of course there won't be any negative ones lol. And NYT bestseller list is so overused i don't even know if it's true? when i was young that sounded really cool i guess?? They have hella books on the bestseller list. how do they know anyways. I once dated a girl who worked in sales at harper collins and i learned a thing or two about the book industry lol.

So somebody would come to my profile in the directory and it would say stay away from this guy, he thinks trump is a piece of poo and writes cuss words all the time. he's a bad dude. and the somebody looking at it would just trust the rating because they trust those guys who write that stuff about people?

Anyway
  

https://www.question2answer.org/


Also has a quite sophisticated user score system that automatically opens up functionality for more trusted users. Initially new users can only make replies and not post new threads for example. Long standing users (with a high post count and lots of "likes") can even be automatically assigned moderator rights.

In general one point that is very important is that starting a community is very different from running an established one. Initially you want to keep the threshold for contributions as low as possible I guess.

  
!Hubzilla Support Forum !Hubzilla Development

Took a bit to track down, but a couple of my RSS feeds include URL's that are longer than the allowable value of item.mid. The result it a bunch of duplicate items in the item table with item.parent=0. In certain instances, this results in a problem on the /network page when the number of item.parent=0 items is close to the page size of selected items. Basically, if all but one or two items has item.parent=0, and you are displaying by "Commented Date", then only one or two items shows up on the /network page and, because the content window doesn't expand far enough, an update never triggers - leaving no way to get more than the 1 or 2 items.

I haven't tracked down the place where duplicates are determined on RSS import (any pointers would be helpful). But since item.mid is supposed to be a globally unique message identifier, it's reasonable to think that it is used to determine duplicates. Would it be inadvisable to change the item.mid from using the article URL for RSS feed items to some sort of hash of the URL that would guarantee that it wouldn't exceed the size of the field? Could we then store the URL in the iconfig table to be retrieved when item.item_rss=1 ?

Note: It also appears that item.llink may be overflowing as well in these instances.
  
@M. Dent i had to revert the distinct in the network query again because of performance reasons (also it would still need a tweek to work on postgres that way). The network load time was increased to about 5 seconds from about 1 second with this change on my development server.

We need to either sort the performance issue out or find another solution i am afraid...
  
No problem, it was an attempt... It was only intended to be temporary anyway.
  
Sorry I didn't notice the performance hit. I sit at the end of somewhat oversaturated 4G fixed wireless links and my dev platform is currently suffering a slowdown in TCP session setup that I'm working with the ISP ablout. Between those 2 things, the performance difference was nearly unnoticeable

  
!Hubzilla Development !Hubzilla Support Forum

Info on the current status of the CART addon and some developer documentation for those who may want to extend the system. The documentation on the current HOOKS needs to be updated as there have been some changes since it was first put together.

[ Hubzilla Cart Addon ] Documentation - Home

!Hubzilla Cart Addon
  
A reservation system like that is beyond the scope of what most people would need, but it is an interesting concept. The raw capabilities of the core module support the basics of order trackibg so it would obviously require additional functionality to be written to accomplish any sort of reservation system.

Non-local channels able to sell on a marketplace presents a number of challenges in itself - none of them completely insurmountable, but challenges nonetheless, which is one reason it is kind of a wishlist/idea item.
  
The hotel part was just an example... I wasn't specifically talking about a reservation system (although that would be cool also).

What I wanted to bring across (but apparently failed) is the idea of multiple stores on multiple Hubzilla instances feeding into one search-able and sort-able aggregation page that acts like Ebay or something like that.
  
I see... Interesting.

I see that Hubzilla could certainly help facilitate such a system, as I quickly think through things, there are a number of problems that would need to be solved if it needed to keep any sort of "real time" availability status.

If it we're just "pointers" to where products may be found - that may be possible. But I think that would be the extent of what the native Hubzilla functionality could provide. And even that would require a whole separate addon to accomplish.

  
!Hubzilla Development

MAYBE just had an idea... of course, it's probably been thought of... but in case it hasn't........

I have to summarize this quick because I'm walking out the door --- if it's incomprehensible, sorry - I'll try to explain it more later.

posting_host polls forum_host to see if requesting_channel is in the forum before allowing access to the file. Could be tokenized in a 3-way handshake (requesting_channel_host gets token from forum_host to that requesting_channel_browser presents to posting_host which is validated with forum_host).

Delegation could be represented in the DB on the posting_host in attach.allow_cid as instead of

Like I said... QUICK summary - feel free to shoot it down - or ask questions.
  
*** Of course, if you are talking about those who want Hubzilla to be merely another of the alphabet soup "social media platforms" and see the inherent privacy and permission system as an impediment and so want to circumvent them, I say holding a STRONG line against that is good and right! But I don't see that as my aim (I could be wrong... I may be just trying to rationalize, but I don't think so).
  
I think I might have a concept that's workable. That's one of the nice things about an hour commute - you can flesh out things like this without any distractions.

From the user/member point of you, there's one more tick box on the privacy settings *if* you have a restricted privacy role. "Give attached media viewing permission to conversation owner" or words to that effect. This solves the comment problem because that's exactly what we want. For tagged forum posts we can use the same words, but in this case we're still the conversation owner on this site. But... the forum is the owner of every copy that they send out, so the text still works. It just needs special handling on post submission to identify any tagged forums.

Implementation wise, when this box is ticked we check on post submission and add the portable_id (xchan_hash) of the conversation owner and/or any tagged forums to the ACL in allow_gid (this is to distinguish between collective usage from individual usage which goes into allow_cid ).

Now all that remains is permission checking. We already create a list of all privacy groups you're a member of on this site so that we can check those (init_groups_visitor()). I'd suggest building a list of all the channels that you're connected to, using the xlink (friends of friends) table rather than the abook table. These can be qualified/filtered with "on this site OR forums"  logic to keep the list managable and avoid hitting any limits. It also should keep performance "reasonable". Merge this list with the init_groups_visitor() ids.

Done.

The xlink table is updated approximately daily via cron. It only contains results for connections that let you view their connections. So from a security perspective everything works.
  
In many ways, I miss my commute... in others, a walk across the parking lot to the office is quite the blessing!

A few points are a bit murky - but only because I am still learning some of the underlying data structures. From what I can follow and piece together, it sounds like it covers everything nicely.