• Dadman with a boy
  • Posts: 16,079
Let's discuss privacy openly!
« on August 18th, 2014, 12:20 PM »
So... Hopefully I'll get some feedback on this. If not, at least writing my thoughts helps me sort them out a little.

Currently, Wedge does privacy[1] by storing data in different places. Profile privacy is stored in the profile owner's member data field (which is the perfect place for it, unless you start wanting to access this data from a place where ALL profile fields are requested, thankfully there aren't many), and topic privacy is stored in a field in the topics table, which is pretty much the opposite way of doing it: it's made with, in the mind, the idea that places that query multiple topics will want to access it, but nothing more, that is, you lose flexibility in favor of speed because you can't store multiple groups or lists or member IDs or whatever in it.

Now, a *privacy table* is something I left aside for as long as I could, because it forces me to:
(1) do a table join pretty much everywhere (okay, I can do a subselect from within {query_see_topic}[2], but I don't know if it'll hurt overall performance),
(2) insert a 'dummy' entry for each and every topic, including existing ones (which can be done through the upgrade script), meaning there'll be lots of useless data, i.e. id_group = 0 on the large majority of entries, possibly causing the same kind of performance problems that SMF has been having on large boards with the 'approved' bit. Meh...

But there are also other advantages:
(1) it can easily be extended by plugins (so that they can have their own privacy settings without the need for a new privacy table),
(2) speed could be better than any other solution, provided we cook up the 'perfect' system, and I'm afraid I alone can't build a proper efficient table,
(3) multiple privacy entries for everyone and everything,
(4) and it's cleaner.

So, I'm looking into preparing for that, and asking for feedback, suggestions, and alternatives I might have not thought about.

This is the preliminary, simplified privacy table structure I'm currently looking into.

wedge_privacy {
  int: privacy_type (could be profile, topic, media album, etc.)
  int: id_context (could be a topic ID, or a profile area like 'age', turned into a number...)
  int: id_member (member ID of the owner -- useful for profiles)
  int: id_target_member (member ID of someone who's given specific access to this, otherwise empty)
  signed int: id_group (could be: 0 for everyone, 1 for members, 99 for just the author, 100+ for a contact list ID, -1 and below for a membergroup)
  anything else..?

Maybe I should split privacy tables into two: one for topics, and one for all the rest... That way, the topic table wouldn't hurt performance for other privacy items.
Or, I could skip the whole 'have to have an entry for each topic', and add a flag to the topic table, saying whether it's a public topic (no privacy entry), or a topic referred to in the privacy table. I can't have it directly refer to a privacy table entry, as that would prevent me from adding multiple groups or lists for the topic.

Or if it's too complicated for you, just feel free to chip in regarding how you'd like me to deal with privacy on a user's point of view. For instance, do you like the idea that you can have multiple lists per privacy item (something I didn't even consider when I first built the feature, because I figured one could simply build a new list out of people you want to include from other lists, but then it can get crowded quick...), or individual member IDs per item (a feature that's actually already in Aeva Media, so I'll have to rewrite/force it into the new privacy system, but at least it's something you'll be familiar with).

In fact, I noticed this week (because I was looking into privacy settings for posting pictures of my kid) that Facebook (recently?) added a 'Custom' privacy setting which is really, really not all that obvious to the eye, but that pretty much allows you to do everything I'm planning to have... It doesn't have "Members" though (i.e. the ability to determine whether unlogged guests can see something), but it has "Friends of friends", which is something I'm not sure I want to have in Wedge... Well, you know, things like that, I'm all for your feedback, guys!
 1. And the simple fact that it's the ONLY forum system to do it AFAIK is quite upsetting! Although it's also one of these 'killer' features in the killer app that is Wedge, so it's both upsetting and reassuring for me. :lol:
 2. Thus something like SELECT id_topic FROM wedge_topics AS t WHERE ... AND (SELECT ... FROM wedge_privacy AS wp WHERE t.id_topic = wp.id_topic AND wp.privacy_type = PRIVACY_TYPE_TOPIC AND ((wp.id_target_member = {int:me} OR wp.id_group IN {array_int:my_lists_and_groups})... That looks VERY bad to me!


  • Posts: 343
Re: Let's discuss privacy openly!
« Reply #1, on August 18th, 2014, 05:27 PM »
I like it but as a user i dont know if i really would use that feature.
And i dont like that every privacy button can be used to change my own settings. If I view someone elses profile I can change with a click my own settings.
Also i think it would be perhaps better to locate those buttons in modify forum profile?!


  • Dadman with a boy
  • Posts: 16,079
Re: Let's discuss privacy openly!
« Reply #2, on August 18th, 2014, 11:24 PM »
Sorry, changing settings on someone else's page was a bug on my side. I was actually careful in disabling editing on other profiles, but recently I made a change that broke it. Of course security-wise it's only YOUR profile that gets affected so it's no big deal, but still... Fixed.

No, I don't want to have these in a non-obvious area, because I want ANYONE to be able to *quickly* change what people can see. And, basically, these icons do well their job: they draw your attention.
I don't know if I should show the icons for non-owners, though.. I'm only hiding them from guests, for now.

Anyway, looking for feedback on my original post!


  • Living on the edge of Wedge
  • Posts: 635
Re: Let's discuss privacy openly!
« Reply #5, on September 2nd, 2014, 11:35 AM »
Lightyears ago I mentioned the advantage of a seperate privacy table. :)
I like the idea.
Especially it's a milestone for Plugins to deal with privacy settings.

If you only would MyISAM left aside...
InnoDB is so smart, when it come to table / query caching.
Therefor you don't have to worry about an subquery and table locks.
Let MySQL decide which layout to use. It's stable and more crash save than MyISAM.
Take a look at Facebooks implementation of InnoDB!
There's a reason they are using it.

What's more efficient?
Hmm... we must try.
Have a flag in topic table is the easiest solution.
Have two privacy tables is more clean and logical.
I would prefer the second solution, because who knows where we will go with privacy in the future. :)

Re: Let's discuss privacy openly!
« Reply #6, on September 2nd, 2014, 11:52 AM »
I'm running Wedge on InnoDB with compressed tables. This is rocking cool and fast.
# dpkg-reconfigure brain
error: brain is not installed or configured