Simple Machines Community Forum

SMF Development => Feature Requests => Next SMF Discussion => Topic started by: Xarcell on October 06, 2011, 01:51:46 AM

Title: My SMF 3.0 Dream
Post by: Xarcell on October 06, 2011, 01:51:46 AM
Personally I think 2.1 should be skipped and go straight into developing on 3.0.

My 3.0 Dream:

1.| Use HTML 5 especially with the use of microdata. The way I see it, but the time 3.0 comes out, there will be a lot more support for it.

2.| Go Object Oriented.

3.| Keep your ground on not supporting third party software. jQuery "might" being the only exception, as some don't consider it third party. However, it should be discussed publicly on whether to support it or not. The pros may out-weigh the cons greatly.

4.| Add a BBC manager and a Menu Manager.

5.| Rename "Default Theme" to "Master Theme", and use the term "Default Theme" when applying a theme to run as the site default. This makes things a little clearer for newcomers.

6.| Remove most of the profile fields in profiles and let the custom profile fields do the work. If the admin wants them, he can create them.

7.| Remove the Calendar. I actually have mixed feeling about this, because I use the Calendar. I think it should be an "official" mod.

8.| Permissions need a make-over. Current system is to complicated to understand for newcomers. Adding options like "Accept" "Deny" and "Revoke" can be a game changer and help people understand it better. Using "Deny" means no permission, but can get permission that allows you from another group. However, using "Revoke" means no permission, regardless if you get permission from another group.

9.| Full UTF8 support by default.

10.| Look at "PHP Speedy (http://aciddrop.com/php-speedy/)"(uses GZIP compression to reduce browser overhead), this idea has potential. Can SMF have something similar by default, that combines all JS files into one file and CSS files into one file(including additional JS/CSS files from mods), and removes white-space and comments. This will reduce HTTP requests and file sizes. Not speed up not only page loading by a little bit, but increase browser load speed greatly on slower computers.

11.| Make notification a numbered queue like facebook alerts, rather than sending an email.

12.| Add user tagging, meaning I can tag a user in a message(@Xarcell) and receive an notification that my name was tagged. It lets me know a comment was directed towards me. To cut down on abuse, you should only be able tag users that are participating within that topic. Also have an option to ignore those notifications for a particular topic.

13.| More CSS3 support, less IE6 support.

14.| Default theme(or "Master Theme" if you will), should have better smart-phone/tablet support out-of-box. Heck, look at windows 8.

15.| Eliminate as many images as you can. SMF uses way too many icons. Many of them can be created using pure CSS, like the "new" button. Reduce HTTP requests and page load.

16.| Eliminate post page, expand Quick Reply and use ajax.

17.| Continue support for multiple database types.

18.| URL's need to be prettier. Site domain followed by the category name, numeric topic id, and then numeric reply id if any. Example: "simplemachines.org/smf-development/feature-requests/topic=31689/". Each reply go in numeric order, example: "simplemachines.org/smf-development/feature-requests/topic=31689/reply=1/".

19.| For the love of GOD, don't add a sidebar, it won't be flexible enough. All or nothing. If you want to do such as thing, then do it properly. Allow blocks of content to be displayed around the forum. Much like your common portals. Top, bottom, left, and right.

20.| Option to apply any age, gender, or custom profile field into a membergroup, so that it can be given permissions. This would allow sites to restrict content by age, gender, or custom profile field. This is something I have not seen any software do, but is always asked for as a mod/add-on.

21.| No more gifs! SVG should be used with a PNG fallback(javascript needed to do this until it becomes fully supported) where applicable.

22.| Scrap karma system for users and add like/dislike system based on posts.

23.| Use overlays where applicable.

24.| Profiles need a make-over, add more information and ditch the old YaBB look. Be sure to add page views a profile, and show what the user is currently viewing.

25.| Full Litespeed support.

26.| Allow multiple polls per topic.

27.| Expand buddy system to include following their activity & posts.

28.| Add option to appoint a membergroup moderator, which add add/remove users from that particular membergroup.

29.| Option to use custom on/off images per board.

30.| Use jQuery as library of choice and/or jQuery mobile.

31.| Add "drag & drop" for arranging for categories/boards, and profile fields. Also any other areas where useful.

32.| Option to add attachments in PM's.

33.| phpinfo should be shown in admin section.

34.| Add default avatar, brings uniform to forum.



Help Forums Evolve!

1.| There should be an option to display a topic as an "article", "page", "file", "thread", or "blog". Really if you think about it, the only different between the four is HOW the information is displayed. Selecting between the five options merely changes which template can be used to display that information.

Membergroup permissions determine what type can be used, along with what code such as BBC, HTML, or PHP. An example of default restrictions would be Page & PHP is allowed by the admin only.

If your wondering what "file" type is, then it's nothing more than taking a post with an attachment and display to look like a item download page. All the information is there, it's just a manner of how to display it.

It would also make it easier to make an add-on for it. Someone might want a custom "reviews" add-on, that mainly just displays the information within the post to look like a review page.

2.| All content of any type can all be found within the forum. No need for separate sections. Actions(such as the calendar) show even be allowed to placed into a forum category. So there should be an option for every action to do this or not(Google doesn't like redirects). Either way though, everything that a forum has, should have an option be able to be found within the forum itself, including the member base. The forum index should be the sitemap!

3.| I'm not for third party support, but I think people should be able to login and post using their Facebook, Twitter, OpenID, Yahoo, Live, and Google login's without registering or creating a profile.

Title: Re: My SMF 3.0 Dream
Post by: Fustrate on October 09, 2011, 06:31:02 PM
1. Of course.
2. Confirmed.
3. I'd rather use something that is known to work than try to reinvent the wheel. Everyone here knows the mess we call the SMF WYSIWYG editor :P



7. Yep, I agree.
8. Yep, I agree, though it would be "Allow, Deny, No Action" or something like that.
9. Of course.
10. I'd like that.



13. Yep, I agree. IE6 people should know to expect a more basic experience (though it should still work).



15. Agreed.
16. I wouldn't eliminate the post page, but I'd certainly expand QR.
17. Yes, but let's not reinvent the wheel, as I said earlier.
18. Yes, but there are better formats.



21. PNG for most little images, CSS3 for most other things. Why mess with SVG?
22. Karma should be removed.



30. jQuery, yes, jQuery mobile, no. jQuery mobile is much more suited to themes that want to use it.
31. That's just aesthetics, not a big deal.
32. Bad idea - what happens when two members decide to send child pornography to each other? It's illegal, and because it's a private message, you wouldn't be able to find out about it.
Title: Re: My SMF 3.0 Dream
Post by: KensonPlays on October 25, 2011, 06:11:06 PM
The ones that I keep in the quote are the ones I agree with:

Quote from: Xarcell link=topic=454917.msg3178169#msg3178169 date=1317880306
[b
1[/b].| Use HTML 5 especially with the use of microdata. The way I see it, but the time 3.0 comes out, there will be a lot more support for it. - Yes, HTML5 is the new standard, so HTML5/PHP would be a great combination!

2 - I'm not familiar with OOP, so meh...

3.| Keep your ground on not supporting third party software. jQuery "might" being the only exception, as some don't consider it third party. - I completely agree with jQuery.

4.| Add a BBC manager and a Menu Manager. - Menu Manager might not be NEEDED unless you have a portal, or pages to connect them to. I'm sure a lot of people only use the forum feature by itself.

5.| Rename "Default Theme" to "Master Theme", and use the term "Default Theme" when applying a theme to run as the site default. This makes things a little clearer for newcomers. - I totally agree

6.| Remove most of the profile fields in profiles and let the custom profile fields do the work. If the admin wants them, he can create them. - Yes, I agree

7.| Remove the Calendar. I actually have mixed feeling about this, because I use the Calendar. I think it should be an "official" mod. - Yes, I agree

10.| Look at "PHP Speedy (http://aciddrop.com/php-speedy/)"(uses GZIP compression to reduce browser overhead), this idea has potential. - Yes, I agree

11.| Make notification a numbered queue like facebook alerts, rather than sending an email. - Yes, I agree

12.| Add user tagging, meaning I can tag a user in a message(@Xarcell) and receive an notification that my name was tagged. It lets me know a comment was directed towards me. To cut down on abuse, you should only be able tag users that are participating within that topic. Also have an option to ignore those notifications for a particular topic.  - Yes, I agree

13.| More CSS3 support, less IE6 support. - Yes, I agree

14.| Default theme(or "Master Theme" if you will), should have better smart-phone/tablet support out-of-box. Heck, look at windows 8. - Yes, I agree

15.| Eliminate as many images as you can. SMF uses way too many icons. Many of them can be created using pure CSS, like the "new" button. Reduce HTTP requests and page load. - Yes, I agree, with CSS3 less and less images are needed for greater pageloads.

16.| Eliminate post page, expand Quick Reply and use ajax. - Yes, I agree

17.| Continue support for multiple database types. - I'm kind of in the middle here. MYSQL is the most popular, maybe the top 2 database types, because the others really aren't used.

18.| URL's need to be prettier. Site domain followed by the category name, numeric topic id, and then numeric reply id if any. - Pretty URLs modification can do this well enough IMO.

19.| For the love of GOD, don't add a sidebar, it won't be flexible enough. All or nothing. If you want to do such as thing, then do it properly. Allow blocks of content to be displayed around the forum. Much like your common portals. Top, bottom, left, and right. - Yes, I agree

20.| Option to apply any age, gender, or custom profile field into a membergroup, so that it can be given permissions.
This would allow sites to restrict content by age, gender, or custom profile field. This is something I have not seen any software do, but is always asked for as a mod/add-on. - Yes, I think this would work. Age or custom profile field will be good enough, I don't wanna be sexist!

21.| No more gifs! SVG should be used with a PNG fallback(javascript needed to do this until it becomes fully supported) where applicable. - Yes, I agree

22.| Scrap karma system for users and add like/dislike system based on posts. - Meh, maybe both, you can select if you want a like/dislike or a karma (rep) system

23.| Use overlays where applicable. - ?_?

24.| Profiles need a make-over, add more information and ditch the old YaBB look. Be sure to add page views a profile, and show what the user is currently viewing. - Yes, I agree

25.| Full Litespeed support. - Yes, I agree even though I don't know what litespeed is, it sounds great :P

26.| Allow multiple polls per topic. - Yes, I agree

27.| Expand buddy system to include following their activity & posts. - Yes, I agree

28.| Add option to appoint a membergroup moderator, which add add/remove users from that particular membergroup. - Yes, I agree

29.| Option to use custom on/off images per board. - Yes, I agree (BUT... Custom Board Icons mod can do the trick well enough)

30.| Use jQuery as library of choice and/or jQuery mobile. - Yes, I agree. jQuery is awesome, I played around with it for a tiny bit and loved it!

31.| Add "drag & drop" for arranging for categories/boards, and profile fields. Also any other areas where useful. - Yes, I agree. This would make SMF more modern, take a look at Concrete5's system. In-page editing. Click a button in the admin menu bar at the top to edit the page. Same with boards/categories. This would make SMF awesomer :P

32.| Option to add attachments in PM's. - Yes, I agree, basic attachments at least...

33.| phpinfo should be shown in admin section. - Yes, I agree, you wouldn't need to code a custom page using phpinfo(); because new users/non-coders won't know how.

34.| Add default avatar, brings uniform to forum. - Yes, I agree



3.| I'm not for third party support, but I think people should be able to login and post using their Facebook, Twitter, OpenID, Yahoo, Live, and Google login's without registering or creating a profile. - Yes, I agree
Title: Re: My SMF 3.0 Dream
Post by: Anthony` on October 25, 2011, 06:22:02 PM
A lot of great suggestions, I wont reply individually, but know that you have my support for most of these points.
Title: Re: My SMF 3.0 Dream
Post by: Kindred on October 26, 2011, 11:08:39 AM
pretty urls are pointless....

and attachments in PM is a bad idea.   If someone distributes illegal or copyrighted material via PM, this now makes the ADMIN responsible....   and the admin can not (easily) scan PMs.

Title: Re: My SMF 3.0 Dream
Post by: KensonPlays on October 26, 2011, 11:41:24 AM
OK. What do you think about the others?
Title: Re: My SMF 3.0 Dream
Post by: Kindred on October 26, 2011, 11:56:46 AM
most of them are a toos-up for me.  I can see some of them being useful - many of them are already mods.

I have no specific argument with them and would leave it up to our developers to decide if they wanted to do it or not.
Title: Re: My SMF 3.0 Dream
Post by: DoctorMalboro on October 26, 2011, 12:37:58 PM
I don't agree in 17 and 18, mainly because people are not likely to use SQLite and PostgreSQL and for me, MySQL can work in both ways perfectly...

Then, Pretty URLs shouldn't be standar, because it's just a matter of the user, maybe as an option but disabled, kind of like many CMS do...

Then, in 21, I don't see the point of using SVG when they weight pretty much the same as PNG (in my experience using it, of course)...

I would add a better support to multimedia attachments (like videos with popcorn.js and multiple images with a slideshow) and if the use of CSS3 is likely to happen, create a basic color changer with JavaScript would look great (and remove all the default simple variations)...
Title: Re: My SMF 3.0 Dream
Post by: Oldiesmann on October 27, 2011, 01:17:38 PM
Personally I think 2.1 should be skipped and go straight into developing on 3.0.

My 3.0 Dream:

1.| Use HTML 5 especially with the use of microdata. The way I see it, but the time 3.0 comes out, there will be a lot more support for it.

2.| Go Object Oriented.

3.| Keep your ground on not supporting third party software. jQuery "might" being the only exception, as some don't consider it third party. However, it should be discussed publicly on whether to support it or not. The pros may out-weigh the cons greatly.

4.| Add a BBC manager and a Menu Manager.

5.| Rename "Default Theme" to "Master Theme", and use the term "Default Theme" when applying a theme to run as the site default. This makes things a little clearer for newcomers.

6.| Remove most of the profile fields in profiles and let the custom profile fields do the work. If the admin wants them, he can create them.

7.| Remove the Calendar. I actually have mixed feeling about this, because I use the Calendar. I think it should be an "official" mod.

8.| Permissions need a make-over. Current system is to complicated to understand for newcomers. Adding options like "Accept" "Deny" and "Revoke" can be a game changer and help people understand it better. Using "Deny" means no permission, but can get permission that allows you from another group. However, using "Revoke" means no permission, regardless if you get permission from another group.

9.| Full UTF8 support by default.

10.| Look at "PHP Speedy (http://aciddrop.com/php-speedy/)"(uses GZIP compression to reduce browser overhead), this idea has potential. Can SMF have something similar by default, that combines all JS files into one file and CSS files into one file(including additional JS/CSS files from mods), and removes white-space and comments. This will reduce HTTP requests and file sizes. Not speed up not only page loading by a little bit, but increase browser load speed greatly on slower computers.

11.| Make notification a numbered queue like facebook alerts, rather than sending an email.

12.| Add user tagging, meaning I can tag a user in a message(@Xarcell) and receive an notification that my name was tagged. It lets me know a comment was directed towards me. To cut down on abuse, you should only be able tag users that are participating within that topic. Also have an option to ignore those notifications for a particular topic.

13.| More CSS3 support, less IE6 support.

14.| Default theme(or "Master Theme" if you will), should have better smart-phone/tablet support out-of-box. Heck, look at windows 8.

15.| Eliminate as many images as you can. SMF uses way too many icons. Many of them can be created using pure CSS, like the "new" button. Reduce HTTP requests and page load.

16.| Eliminate post page, expand Quick Reply and use ajax.

17.| Continue support for multiple database types.

18.| URL's need to be prettier. Site domain followed by the category name, numeric topic id, and then numeric reply id if any. Example: "simplemachines.org/smf-development/feature-requests/topic=31689/". Each reply go in numeric order, example: "simplemachines.org/smf-development/feature-requests/topic=31689/reply=1/".

19.| For the love of GOD, don't add a sidebar, it won't be flexible enough. All or nothing. If you want to do such as thing, then do it properly. Allow blocks of content to be displayed around the forum. Much like your common portals. Top, bottom, left, and right.

20.| Option to apply any age, gender, or custom profile field into a membergroup, so that it can be given permissions. This would allow sites to restrict content by age, gender, or custom profile field. This is something I have not seen any software do, but is always asked for as a mod/add-on.

21.| No more gifs! SVG should be used with a PNG fallback(javascript needed to do this until it becomes fully supported) where applicable.

22.| Scrap karma system for users and add like/dislike system based on posts.

23.| Use overlays where applicable.

24.| Profiles need a make-over, add more information and ditch the old YaBB look. Be sure to add page views a profile, and show what the user is currently viewing.

25.| Full Litespeed support.

26.| Allow multiple polls per topic.

27.| Expand buddy system to include following their activity & posts.

28.| Add option to appoint a membergroup moderator, which add add/remove users from that particular membergroup.

29.| Option to use custom on/off images per board.

30.| Use jQuery as library of choice and/or jQuery mobile.

31.| Add "drag & drop" for arranging for categories/boards, and profile fields. Also any other areas where useful.

32.| Option to add attachments in PM's.

33.| phpinfo should be shown in admin section.

34.| Add default avatar, brings uniform to forum.



Help Forums Evolve!

1.| There should be an option to display a topic as an "article", "page", "file", "thread", or "blog". Really if you think about it, the only different between the four is HOW the information is displayed. Selecting between the five options merely changes which template can be used to display that information.

Membergroup permissions determine what type can be used, along with what code such as BBC, HTML, or PHP. An example of default restrictions would be Page & PHP is allowed by the admin only.

If your wondering what "file" type is, then it's nothing more than taking a post with an attachment and display to look like a item download page. All the information is there, it's just a manner of how to display it.

It would also make it easier to make an add-on for it. Someone might want a custom "reviews" add-on, that mainly just displays the information within the post to look like a review page.

2.| All content of any type can all be found within the forum. No need for separate sections. Actions(such as the calendar) show even be allowed to placed into a forum category. So there should be an option for every action to do this or not(Google doesn't like redirects). Either way though, everything that a forum has, should have an option be able to be found within the forum itself, including the member base. The forum index should be the sitemap!

3.| I'm not for third party support, but I think people should be able to login and post using their Facebook, Twitter, OpenID, Yahoo, Live, and Google login's without registering or creating a profile.



1. I agree.
2. Fine with me as well. Might make things more flexible.
3. I agree here as well. jQuery can be quite useful, and is very well supported, so I see no reason why we can't use it.
4. Not really sure on this one. Menu options are easy enough to add now - they just require a file edit. BBCode on the other hand would be nice, as our current system is much too confusing for those not familiar with PHP and such.
5. Agree here as well.
6. Agree, but we should have some standard fields defined by default, and let the admin change/remove them if they aren't wanted.
7. Mixed feelings on this as well. The biggest request in this area over the years has been to add more features (recurring events and the like), so removing it, even if it's kept as an official mod, might annoy people.
8. Agree. SMF's permissions system is quite powerful, but the current setup tends to confuse people more than anything.
9. Definitely. MySQL 4.0 is so ancient now that we should have no issues with dropping support for it in order to have full UTF8 support out of the box.
10. Interesting idea, but removing linebreaks, etc. from generated source might make it harder to debug things.
11. I agree as well. IPB has already moved in this direction and I love their current notifications system.
12. Agree, as long as it won't add a lot of overhead and can be disabled (not everyone wants to get notified when they're tagged)
13, 14 and 15: Agree
16. I would prefer to keep the post page. Adding more features to the Quick Reply is a good idea as long as we have control over it (some of us like the bare-bones quick reply :P).
17. Agreed. Just because Postgres and SQLite aren't as common as MySQL doesn't mean we shouldn't support them.
18. Disagree. Let's leave this one to mods.
19. Agree as well. Everytime I go to a forum which has a sidebar, the first thing I do is figure out how to get rid of it. There are portals for this if the admin really wants them.
20. Nice idea. Would definitely be popular. Question is whether it can be done without making things too complicated.
21. On the fence here. SVG is great for larger images that need to scale well, but I'm not sure how SVG would be better for the smaller images that we currently use GIFs for.
22. Like/dislike is all the rage these days, so go for it. Karma system never has been that useful since we never bothered to do anything with it, and very few mods actually use it for anything.
23. No idea what you mean here...
24. I agree as well.
25. Agree. Litespeed is becoming more and more popular, so we should do our best to support it.
26. Yes, especially if we can make dynamic polls (eg the second poll's options are based on what you voted for in the first poll)
27. Yes. Definitely.
28. Already exists :)
29. It's easy enough to replace the images now, so I don't know why we need to dumb it down any further...
30. Yes to jQuery. Don't know enough about the "mobile" version.
31. Yes, as long as it doesn't add a lot of overhead.
32. No, for the reasons already pointed out by others. There are plenty of file-sharing and image-hosting sites for this sort of thing.
33. Yes, as long as it's only available to admins (mainly to prevent whining about possible targeted attacks due to outdated server software :P)
34. Yes

1. Not sure about this. Might make things more confusing in the long run.
2. I think that would make things more confusing. A built-in XML sitemap might be good, but non-forum content should be kept out of the forum itself.
3. I agree here as well.
Title: Re: My SMF 3.0 Dream
Post by: vbgamer45 on October 27, 2011, 01:39:35 PM
1. Use some html5 but not make the forum depend on it. Microdata is good.
2. No OOP there is no major gain and you will just end up rewriting all the code with the same bugs and that will take another couple years to get done. You can do parts that make sense.
3. jquery is nice as long as major parts of the code are not javascript based and depending on what you include does increase the page load time. Would like to see it optional.
4. Agree
5. Can go either way
6. Agree
7. We have the code already no need to remove it.
8. I think that is how it used to be in 1.1.x
9. Tables should be utf8 by default would help with some issues.
10. Looks nice I am big into reducing page loading time
11. Somewhat agree but I think it would be better have a summary either hourly or daily for certain events
12. Net idea
13. CSS3 on the fence it is not even completely defined yet. Would need to see the benefits and what browsers support what.
14. Agree mobile/tablet is needed.
15.Agree
16. Disagree maybe add a couple extra options to quickly
17. Disagree but keep the abstraction layer. Have hardly seen any posts in the other database type forums.
18. Agree.
19. Could go either way
20. Agree
21. Never seen a svg image with a web app. I would be in favor of PNG's over gifs. I don't even know what programs make svg files.
22. Not a big fan of scraping existing features but do like the idea of adding likes/dislikes to posts.

Title: Re: My SMF 3.0 Dream
Post by: Antechinus on October 27, 2011, 05:37:44 PM
1 Yup.

2 Yup.

3 We have already decided to support jQuery as using a pre-existing library makes a lot of sense, and jQ is the de facto standard these days.

4 Yup.

@Oldies: I realise menu edits are easy for us. "Oh, all you have to do is delve into the depths of Sources and edit a complex PHP array. Make sure to get your syntax right or you'll crash your whole site. Have a nice day."

It's not the way to go if you really want to support a broad user base. Most people are not coders and do not want to be coders. They don't feel they have the time to learn coding on top of everything else in their lives. If you want to enable them to run their own forum, you should be making it easy for them.

5 Makes a certain amount of sense.

6 Ditto. Never been a fan of lots of profile fields anyway. Just a few basic ones would do me.

7 Bit of a toss up on whether to keep it as core or not. Not sure at the moment.

8 I agree that permissions need an overhaul.

9 Definitely.

10 I'm all for reducing http requests, and I often merge custom js files and css files when doing custom work anyway. The one exception would be jQuery itself, as calling that from Google CDN makes the most sense since a lot of people will already have that cached. To my mind, the best way of handling jQ would be to call from Google by default, with a fallback to the forum's own copy if the Google file happens to be unavailable for some reason.

11 Never use notifications anyway, so am personally ambivalent about the whole thing.

12 Ditto. I'd probably want an off switch for that one.

13 Definitely. IE6 is only going to be minimally supported. Same for IE7. IOW, we'll probably do a quick check to make sure critical functionality is still operational, but we wont care what it looks like.

14 Yup, or it should come with a separate mobile version (which is probably better, really).

15 Yup.

16 Would keep the post page, but have an option of bare bones or advanced quick reply for those who want it.

17 Yup.

18 Not in favour of pretty url's by default.

19 The plan is to keep it without a sidebar. Anyone who wants extra blocks can install a portal.
 
20 Not a bad idea.

21 Will be using mainly png, but possibly SVG for some things. PNG's are very light if used sensibly (often lighter than gif).

22 Speaking for myself, I would happily scrap karma and not replace it with anything.

23 I'll leave that one to the back end boffins. Me do templates n css. :P

24 So you want fewer profile fields but more stuff in profile? Ok. How does that work? :D

25. Sounds like a good idea.

26 Would be fine with that.

27 Same as notifications. Couldn't care less, so will see what others think.

28 Not sure I'd use it myself, and it does complicate an already complex system, but I can see the sense in the idea.

29 Probably better as a mod. Certainly not something I'd prioritise for core.

30 Already been over that. :)

31 Yes. Menu manager and file uploads are obvious places for this too.

32 I'd like it myself, and will probably add custom code for it so staff can use such a function, but not a good idea for general use/inclusion in core.

33 Makes sense.

34 Ditto.



Help Forums Evolve!

Quote
1.| There should be an option to display a topic as an "article", "page", "file", "thread", or "blog". Really if you think about it, the only different between the four is HOW the information is displayed. Selecting between the five options merely changes which template can be used to display that information.

Membergroup permissions determine what type can be used, along with what code such as BBC, HTML, or PHP. An example of default restrictions would be Page & PHP is allowed by the admin only.

If your wondering what "file" type is, then it's nothing more than taking a post with an attachment and display to look like a item download page. All the information is there, it's just a manner of how to display it.

It would also make it easier to make an add-on for it. Someone might want a custom "reviews" add-on, that mainly just displays the information within the post to look like a review page.

Interesting thoughts, but offhand I'm inclined to think that this is where portals start to make sense as they allow similar things already. Not entirely sure it makes sense for a forum core module.

Quote
2.| All content of any type can all be found within the forum. No need for separate sections. Actions(such as the calendar) show even be allowed to placed into a forum category. So there should be an option for every action to do this or not(Google doesn't like redirects). Either way though, everything that a forum has, should have an option be able to be found within the forum itself, including the member base. The forum index should be the sitemap!

Not sure how well that would actually work.

Quote
3.| I'm not for third party support, but I think people should be able to login and post using their Facebook, Twitter, OpenID, Yahoo, Live, and Google login's without registering or creating a profile.

Meh, with the obvious exception of OpenID (even though hardly anyone uses it AFAICT).
Title: Re: My SMF 3.0 Dream
Post by: bloc on October 28, 2011, 05:06:24 PM
All of them would be nice to add for SMF 3.0. though I highly doubt most of them will ever make it.

(curiously its a similar wishlist of what I like ViennaBBS to be - except JQuery, Mootools is my choice. But def. the options to show topics as "types" is a "must")
Title: Re: My SMF 3.0 Dream
Post by: kimba on October 28, 2011, 08:53:36 PM
Regarding the option to send attachments in PM, while I agree with what people have said, I'd like to think it is nice to be able to send files to each other. The reason I say this is because people might not want their email address to be public to anyone.

One example this option could prove beneficial would be in a forum such as this one where members might want to send coding scripts to mod/theme creators for review or editing.

However, I do agree that it can cause some legality issue regarding its contents ...
Title: Re: My SMF 3.0 Dream
Post by: Kindred on October 29, 2011, 07:42:36 AM
send scripts using the CODE tag....

Even if attachments in PM was ever included, it would definitely be turned OFF on a forum like this one.
Title: Re: My SMF 3.0 Dream
Post by: Oldiesmann on October 29, 2011, 12:07:37 PM
I personally do not see a need for PM attachments. There are plenty of sites available for sharing whatever it is you'd need to share via PM without having to allow attachments (Pastebin for code; Image Shack, Photobucket and many other sites for images; Pipe Bytes, Dropbox, etc. for files).

The other problem with PM attachments is that we'd have to include a way for admins to manage them just like regular attachments, only with a bit more functionality since the files would be shared between specific members instead of posted in the forum where the admin can see them. We have always been against allowing admins to view their members PMs, and it would be difficult to properly handle PM attachments without allowing admins to view the PMs.
Title: Re: My SMF 3.0 Dream
Post by: Account Abandoned on November 03, 2011, 07:18:59 PM
pretty urls are pointless....

and attachments in PM is a bad idea.   If someone distributes illegal or copyrighted material via PM, this now makes the ADMIN responsible....   and the admin can not (easily) scan PMs.



People can do this through email. I think not adding it because of that reason is a bit paranoid, lol.
Title: Re: My SMF 3.0 Dream
Post by: Kindred on November 03, 2011, 07:47:47 PM
I don't think it's paranoid at all.

If they do it through email, then I am not responsible for any illegal behavior. If they do it on my site, then it could be argued that I am responsible.
Title: Re: My SMF 3.0 Dream
Post by: 青山 素子 on November 03, 2011, 07:55:17 PM
If they do it through email, then I am not responsible for any illegal behavior. If they do it on my site, then it could be argued that I am responsible.

Exactly.

Given the ramming through of the PROTECT IP Act (http://en.wikipedia.org/wiki/Protect_IP_Act) currently going on in Congress in the US, I'd rather not take any chances. The last thing you need is PM attachments containing copyrighted material causing ISPs to remove your entire domain from DNS, advertising companies dropping you and refusing to deal with you, donations being frozen, etc. because a company complained and used the items in this act to shut your site down completely.

(It's like the DMCA take-down process on steroids, and with no judicial oversight.)

Let the e-mail provider handle it, I don't have time or money to file a proper counter-claim and notify all parties that then have to restore me, etc...
Title: Re: My SMF 3.0 Dream
Post by: Account Abandoned on November 05, 2011, 03:23:48 PM
I don't think it's paranoid at all.

If they do it through email, then I am not responsible for any illegal behavior. If they do it on my site, then it could be argued that I am responsible.

If you have a proper terms of service, this can be avoided of course pending the country you live in.
Title: Re: My SMF 3.0 Dream
Post by: Kindred on November 05, 2011, 07:40:31 PM
no, it really can't.   Regardless of what you want to CLAIM in your TOS agreement, *YOU* are held responsible for what is one YOUR site.  Your hosting company will hold you responsible and will shut down your account, if someone even sneezes a DCMA call in your direction.  It won't matter (and they won't even bother to look) - even if you have a ToS that says "you agree that I am not responsible for your actions on my site"

Neither would that legally hold up if someone ended up taking it to court.
Title: Re: My SMF 3.0 Dream
Post by: Oldiesmann on November 06, 2011, 03:05:43 PM
A couple of other things to keep in mind:
Most users don't even read license agreements and similar documents

More importantly, what happens if someone claims ignorance? SMF does not store previous versions of agreement.txt and does not specifically say that the user has agreed to the terms. There's also no guarantee that the "last modified" date on the agreement.txt file will match when you actually last modified it - especially if you have switched hosts at some point over the years.
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on November 07, 2011, 04:47:54 AM
Ok, why not allow an admin to view all attachments sent over PM?  If this feature were implemented, it could be noted to the user in the same area where they attach files within their messages.  Stating the membergroups that will be able to view their Private Messages (to the user), and perhaps even make it able to be approved.  Since the Owner of the site may be held responsible for it, why not give them the option to do it, and provide a means for them to moderate it COMPLETELY!  Private messages should be private, but attachments in these message, to me, should be public to a select member group (that the admin decides).  But, most importantly, the user who sends the attachment(s) should be notified that they are sending a PUBLIC attachment within a Private message.  Public meaning, it is possible for the Admin and other membergroups to view the content of an attachment if they deem so, in order to make sure that the content is allowed on their forum, or not.

Personally I think 2.1 should be skipped and go straight into developing on 3.0.

My 3.0 Dream:

1.| Use HTML 5 especially with the use of microdata. The way I see it, but the time 3.0 comes out, there will be a lot more support for it.

2.| Go Object Oriented.

3.| Keep your ground on not supporting third party software. jQuery "might" being the only exception, as some don't consider it third party. However, it should be discussed publicly on whether to support it or not. The pros may out-weigh the cons greatly.

4.| Add a BBC manager and a Menu Manager.

5.| Rename "Default Theme" to "Master Theme", and use the term "Default Theme" when applying a theme to run as the site default. This makes things a little clearer for newcomers.

6.| Remove most of the profile fields in profiles and let the custom profile fields do the work. If the admin wants them, he can create them.

7.| Remove the Calendar. I actually have mixed feeling about this, because I use the Calendar. I think it should be an "official" mod.

8.| Permissions need a make-over. Current system is to complicated to understand for newcomers. Adding options like "Accept" "Deny" and "Revoke" can be a game changer and help people understand it better. Using "Deny" means no permission, but can get permission that allows you from another group. However, using "Revoke" means no permission, regardless if you get permission from another group.

9.| Full UTF8 support by default.

10.| Look at "PHP Speedy (http://aciddrop.com/php-speedy/)"(uses GZIP compression to reduce browser overhead), this idea has potential. Can SMF have something similar by default, that combines all JS files into one file and CSS files into one file(including additional JS/CSS files from mods), and removes white-space and comments. This will reduce HTTP requests and file sizes. Not speed up not only page loading by a little bit, but increase browser load speed greatly on slower computers.

11.| Make notification a numbered queue like facebook alerts, rather than sending an email.

12.| Add user tagging, meaning I can tag a user in a message(@Xarcell) and receive an notification that my name was tagged. It lets me know a comment was directed towards me. To cut down on abuse, you should only be able tag users that are participating within that topic. Also have an option to ignore those notifications for a particular topic.

13.| More CSS3 support, less IE6 support.

14.| Default theme(or "Master Theme" if you will), should have better smart-phone/tablet support out-of-box. Heck, look at windows 8.

15.| Eliminate as many images as you can. SMF uses way too many icons. Many of them can be created using pure CSS, like the "new" button. Reduce HTTP requests and page load.

16.| Eliminate post page, expand Quick Reply and use ajax.

17.| Continue support for multiple database types.

18.| URL's need to be prettier. Site domain followed by the category name, numeric topic id, and then numeric reply id if any. Example: "simplemachines.org/smf-development/feature-requests/topic=31689/". Each reply go in numeric order, example: "simplemachines.org/smf-development/feature-requests/topic=31689/reply=1/".

19.| For the love of GOD, don't add a sidebar, it won't be flexible enough. All or nothing. If you want to do such as thing, then do it properly. Allow blocks of content to be displayed around the forum. Much like your common portals. Top, bottom, left, and right.

20.| Option to apply any age, gender, or custom profile field into a membergroup, so that it can be given permissions. This would allow sites to restrict content by age, gender, or custom profile field. This is something I have not seen any software do, but is always asked for as a mod/add-on.

21.| No more gifs! SVG should be used with a PNG fallback(javascript needed to do this until it becomes fully supported) where applicable.

22.| Scrap karma system for users and add like/dislike system based on posts.

23.| Use overlays where applicable.

24.| Profiles need a make-over, add more information and ditch the old YaBB look. Be sure to add page views a profile, and show what the user is currently viewing.

25.| Full Litespeed support.

26.| Allow multiple polls per topic.

27.| Expand buddy system to include following their activity & posts.

28.| Add option to appoint a membergroup moderator, which add add/remove users from that particular membergroup.

29.| Option to use custom on/off images per board.

30.| Use jQuery as library of choice and/or jQuery mobile.

31.| Add "drag & drop" for arranging for categories/boards, and profile fields. Also any other areas where useful.

32.| Option to add attachments in PM's.

33.| phpinfo should be shown in admin section.

34.| Add default avatar, brings uniform to forum.



Help Forums Evolve!

1.| There should be an option to display a topic as an "article", "page", "file", "thread", or "blog". Really if you think about it, the only different between the four is HOW the information is displayed. Selecting between the five options merely changes which template can be used to display that information.

Membergroup permissions determine what type can be used, along with what code such as BBC, HTML, or PHP. An example of default restrictions would be Page & PHP is allowed by the admin only.

If your wondering what "file" type is, then it's nothing more than taking a post with an attachment and display to look like a item download page. All the information is there, it's just a manner of how to display it.

It would also make it easier to make an add-on for it. Someone might want a custom "reviews" add-on, that mainly just displays the information within the post to look like a review page.

2.| All content of any type can all be found within the forum. No need for separate sections. Actions(such as the calendar) show even be allowed to placed into a forum category. So there should be an option for every action to do this or not(Google doesn't like redirects). Either way though, everything that a forum has, should have an option be able to be found within the forum itself, including the member base. The forum index should be the sitemap!

3.| I'm not for third party support, but I think people should be able to login and post using their Facebook, Twitter, OpenID, Yahoo, Live, and Google login's without registering or creating a profile.

1. Yes, agree.
2. Not sure if OOP would help SMF or hurt it.  I'm leaning more towards the latter...
3. Definitely.
4. I'm with Oldiesmann on this one.
5. Could be confusing to the Administrator to have a Master Theme and than a Default Theme that are both 1 in the same.
6. Agree, but thinking there should be some sort of selectable way for Admins to add these fields, so that it is easier to do.
7. Most forums come with a Calendar.  Doesn't matter to me whether it is there or not, but if not, should be a Mod Package for it to add it.
8. Yeah, I agree, permission system is a bit of a challenge in trying to understand at first.  And even now, I still struggle with it.  Mainly because it is just too complicated.  Permission Profile Groups in one section, Member Groups in another, etc. etc. just seems a bit scattered around to me.
9. Definitely.
10. Removing white-space and comments might help a bit with speed, but it would make it incredibly hard to debug though, unless the original file was stored somewhere for debugging purposes only.
11. Agree
12. Agree
13. Agree
14. Not sure, haven't seen the support for this yet, don't have a smart-phone/tablet to see what you mean here.
15. Agree
16. I would like to see this happen as well.

Well, that's all the time I have for today.  Those are my opinions though, take it or leave it.
Title: Re: My SMF 3.0 Dream
Post by: Norv on November 07, 2011, 05:04:59 AM
Ok, why not allow an admin to view all attachments sent over PM?  If this feature were implemented, it could be noted to the user in the same area where they attach files within their messages.  Stating the membergroups that will be able to view their Private Messages (to the user), and perhaps even make it able to be approved.  Since the Owner of the site may be held responsible for it, why not give them the option to do it, and provide a means for them to moderate it COMPLETELY!  Private messages should be private, but attachments in these message, to me, should be public to a select member group (that the admin decides).  But, most importantly, the user who sends the attachment(s) should be notified that they are sending a PUBLIC attachment within a Private message.  Public meaning, it is possible for the Admin and other membergroups to view the content of an attachment if they deem so, in order to make sure that the content is allowed on their forum, or not.

That is a possibility. I lean towards NOT doing so, though.

Whether we like it or not, users will want to use PMs for sending files they wouldn't be comfortable with others seeing. (that's part of the reason why they'd use PM anyway, otherwise they'd post them in the boards). Moreover, the next question when this is possible, would be: so admins/these membergroups can read my PMs?
PMs are meant to be person-to-person, and therefore no interface for viewing them will be ever done in SMF. While that has nothing to do with "really confidential", it is still a relevant aspect for what SMF does and encourages.
Title: Re: My SMF 3.0 Dream
Post by: Xarcell on November 07, 2011, 06:15:43 PM
@SoLo

In regards in using "master theme" and "default theme" is by name only. Not 2 separate themes. The default theme should be called the "master theme"(because it's the core theme that modified and what other themes are usually based off of), but when selecting which theme to use as a user, it should say "default theme", because the admin decides which theme installed is the "default theme", which may not be the "master theme".
Title: Re: My SMF 3.0 Dream
Post by: live627 on November 07, 2011, 06:50:39 PM
Quote
Not sure if OOP would help SMF or hurt it.  I'm leaning more towards the latter...
OOP as in WP-like rat's nest or well-designed OOP?
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on November 08, 2011, 02:35:27 AM
Quote
Not sure if OOP would help SMF or hurt it.  I'm leaning more towards the latter...
OOP as in WP-like rat's nest or well-designed OOP?
I'm not a fan of object orientation for the sake of object orientation. Often the proper OO way of doing things ends up being a productivity tax. Sure, objects are the backbone of any modern programming language, but sometimes I can't help feeling that slavish adherence to objects is making life a lot more difficult than it needs to be.  And than ofcourse objects clearly are not enough (as if they ever were), and we find ourselves needing frameworks, components, aspects, services (which, curiously, seems to bring us back to procedural programming!).

@ Xarcell, I think I understand you on this, not sure... sounds valid to me if your idea of expanding templates into any theme is implemented.  Otherwise, it wouldn't make sense to have a master theme to admins and a default theme for users that are both 1 in the same.  IMO, would be better to just have it as 1 name to everyone, or maybe I'm misunderstanding you on this still...?

@ Norv, I understand the meaning of Private, and should be this way.  Just a thought.  I also believe that Private Messages and the content within them should be kept private, however, I also agree that any content that you post belongs to the site (I believe this is in the User Agreement form by default upon Registering, if I'm not mistaken).  If the admin wants to view Private Messages by all members, they can simply go into the database and pull these messages out, so this is an action that the end-user can do, ofcourse, SMF provides this ability to do this, by storing Private Messages within the database and NOT encrypting them.  So in a way, SMF is already guilty of allowing the Admin and anyone who has access to the database, the ability to view PRIVATE and PERSONAL Messages!
Title: Re: My SMF 3.0 Dream
Post by: 青山 素子 on November 08, 2011, 12:25:52 PM
SMF provides this ability to do this, by storing Private Messages within the database and NOT encrypting them.  So in a way, SMF is already guilty of allowing the Admin and anyone who has access to the database, the ability to view PRIVATE and PERSONAL Messages!

I believe this has been discussed before. If they were stored in an encrypted form in the database, the key would still need to be stored somewhere to allow users to actually read the messages.

If it's stored on the server, the admin has access and can still read messages should they want. If the key is stored on the user's machine (via HTML5 Web Storage (http://dev.w3.org/html5/webstorage/) or another mechanism) then that both limits the machines where messages can be read and sent and makes the contents permanently inaccessible if the key is lost from the user's computer. You also have to rely on the forum to not store a plaintext copy.

The privacy of PMs on all forums is subject to the difficulty of accessing the messages. With some forums, you can "impersonate" users, allowing access that way. Others have easy-to-find code that will allow direct reading. With SMF it relies on the fact that there isn't any easy-to-find code, nor way to "become" a user, forcing a database dive that most admins are too unmotivated or unskilled to do.

For more secure PMs over forums, the messages should be using PGP/OpenPGP encryption outside the forum itself.
Title: Re: My SMF 3.0 Dream
Post by: Antechinus on November 08, 2011, 03:28:11 PM
TBH, the reason I don't read people's PM's on the site I run, even though I could do it easily, is because it would be rude and unnecessary. It's the same principle as applies to a lot of social interactions.
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on November 09, 2011, 02:10:57 AM
Just pointing out that storing the actual message itself within the database, without any type of encryption whatsoever is just giving out, atleast to me, a contradictory message than that of what you seem to be saying within this topic about pms, on how personal pms should be.  Yet making them so easy to find in the database.  In any case, it doesn't matter to me.  I don't read other people's pms either, just so you know... not my style!
Title: Re: My SMF 3.0 Dream
Post by: Erbros on November 09, 2011, 06:37:17 AM
This really sounds like a dream come true! :) Keep up the good work and continue developing the best forum software available! :)
Title: Re: My SMF 3.0 Dream
Post by: Xarcell on November 09, 2011, 02:31:06 PM
@SoLo

Your confusing me. I think you are combining two suggestions. Basically, I'm just saying "default theme" should be renamed to "master theme", and that's all for that suggestion. Expanding templates is a different suggestion that nothing to do with whether it's master or default theme.

I only suggestion re-naming the "default theme" to "master theme" only because if the "default theme" is not selected to be the default theme to be shown, it doesn't make sense to call it the default theme. It actually creates confusion for user's trying to explain something in order to get support. Like right now. This suggestion can be made a reality by simply changing a few language strings and the actual name of the default theme, - to master theme. Kinda like "master copy" when it comes to documentation.
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on November 09, 2011, 08:21:29 PM
Ohh, Ok, I see what you mean.  It's not that deep.  Well, again, a default theme to all users on a site, compared to a default SMF theme that comes with SMF are 2 different things, and it's fairly obvious to differentiate between the 2 IMHO.  Master Theme sounds a bit weird to me.  I like the name "default" because, this actually makes a ton of sense, because if language files don't exist within the theme, it defaults to using the default theme to try and load them, if templates don't exist, it defaults to using the default theme, again, to try and load them.  Honestly, even when you have a Custom Theme installed, you are using MANY MANY templates from the DEFAULT theme, not the Custom Theme.  So, in my opinion, default theme is the perfect name for this theme.  So this shouldn't be changed.  And if you just want to associate a default theme to Master Theme on the site when you change to a different default theme in the DP Admin for everyone to use by default, again, I still like the term default.  But to each their own...
Title: Re: My SMF 3.0 Dream
Post by: OCJ on November 13, 2011, 04:54:51 AM
Calendar.
I spend a long time looking at forums and CMSs to provide an events based group. Only SMF does it/everything, 'out of the box' ...

Calendar view, list view, reply to event topic, announce to everyone, reliable mailing system - its perfect.
All I can say is having a good events calendar is becoming popular so why get rid of it - its a growing trend.

After testing many systems in December 2010
MyBB only made made several mods to do the same thing in April 2011.
VBulletin and InvisionPB were not as good as SMF and needed commercial mods (very busy error support forum). As far as I can remember they didnt send out announcements and on one, comments were not allowed. phpBB calendar mod was a mess - not linked to a thread.
SMF performed much better than many CMSs like Joomla and Wordpress for event management, announcement and discussion. Perhaps only Drupal competes but its a lot of work.

For groups that want to manage events, SMF is the best.
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on December 11, 2011, 11:11:37 PM
SMF provides this ability to do this, by storing Private Messages within the database and NOT encrypting them.  So in a way, SMF is already guilty of allowing the Admin and anyone who has access to the database, the ability to view PRIVATE and PERSONAL Messages!

I believe this has been discussed before. If they were stored in an encrypted form in the database, the key would still need to be stored somewhere to allow users to actually read the messages.

If it's stored on the server, the admin has access and can still read messages should they want. If the key is stored on the user's machine (via HTML5 Web Storage (http://dev.w3.org/html5/webstorage/) or another mechanism) then that both limits the machines where messages can be read and sent and makes the contents permanently inaccessible if the key is lost from the user's computer. You also have to rely on the forum to not store a plaintext copy.

The privacy of PMs on all forums is subject to the difficulty of accessing the messages. With some forums, you can "impersonate" users, allowing access that way. Others have easy-to-find code that will allow direct reading. With SMF it relies on the fact that there isn't any easy-to-find code, nor way to "become" a user, forcing a database dive that most admins are too unmotivated or unskilled to do.

For more secure PMs over forums, the messages should be using PGP/OpenPGP encryption outside the forum itself.

A simple base64_encode when inputting into the database and base64_decode after retrieving from the database would be sufficient enough IMHO.  Or even serializing and unserializing it.  But honestly, the fact that it is human readable tells me that you just don't care!
Title: Re: My SMF 3.0 Dream
Post by: 青山 素子 on December 12, 2011, 12:35:41 AM
A simple base64_encode when inputting into the database and base64_decode after retrieving from the database would be sufficient enough IMHO.  Or even serializing and unserializing it.  But honestly, the fact that it is human readable tells me that you just don't care!

If one is just going to do that, why bother? I mean, seriously, how difficult is it to just decode it at that point? If you have enough skill to pull the right tables and display them, it's not even a hurdle to do a base64 decode on the column. As for serializing, plain text is plain text so that won't do anything at all.

One more sure way of "protecting" on the database side is to just use aes_encrypt and aes_decrypt with a key generated at random on an install. Of course, that still doesn't prevent an admin from just changing those calls to not be used and then it's all plaintext on the backend yet again. It also doesn't protect you from an admin that decides to try and login as you so they don't have to dive into the database.

See, that's the thing. Unless you are the only one that has the key, it's not private. Trying to use a forum's personal message system as a secure communication channel is stupid because you (usually) aren't the one with server and code access. Any "rogue" admin that really wants the messages can bypass any protection in the code.

Think of it like a cellular phone call. Communications are encrypted from handset to cell site (that's the base64 on your suggestion), but the network provider has the ability to switch that on or off, or even listen in on the content of any communication going across the network it owns. If you want to use secure communication over that medium, you have to resort to encryption or some secure code that doesn't depend on the medium over which it's being transferred.

So, all you are proposing is to burn CPU cycles on useless mechanisms to possibly make some people feel better for a bit of security theater (http://en.wikipedia.org/wiki/Security_theater). I'd rather use that CPU on something that's actually useful.

So, I suppose you are correct in the accusation that the developers don't care. They don't care to do things that will impact performance and provide absolutely no benefit.
Title: Re: My SMF 3.0 Dream
Post by: Matthew K. on December 12, 2011, 12:42:50 AM
A simple base64_encode when inputting into the database and base64_decode after retrieving from the database would be sufficient enough IMHO.  Or even serializing and unserializing it.  But honestly, the fact that it is human readable tells me that you just don't care!

If one is just going to do that, why bother? I mean, seriously, how difficult is it to just decode it at that point? If you have enough skill to pull the right tables and display them, it's not even a hurdle to do a base64 decode on the column. As for serializing, plain text is plain text so that won't do anything at all.

One more sure way of "protecting" on the database side is to just use aes_encrypt and aes_decrypt with a key generated at random on an install. Of course, that still doesn't prevent an admin from just changing those calls to not be used and then it's all plaintext on the backend yet again. It also doesn't protect you from an admin that decides to try and login as you so they don't have to dive into the database.

See, that's the thing. Unless you are the only one that has the key, it's not private. Trying to use a forum's personal message system as a secure communication channel is stupid because you (usually) aren't the one with server and code access. Any "rogue" admin that really wants the messages can bypass any protection in the code.

Think of it like a cellular phone call. Communications are encrypted from handset to cell site (that's the base64 on your suggestion), but the network provider has the ability to switch that on or off, or even listen in on the content of any communication going across the network it owns. If you want to use secure communication over that medium, you have to resort to encryption or some secure code that doesn't depend on the medium over which it's being transferred.

So, all you are proposing is to burn CPU cycles on useless mechanisms to possibly make some people feel better for a bit of security theater (http://en.wikipedia.org/wiki/Security_theater). I'd rather use that CPU on something that's actually useful.

So, I suppose you are correct in the accusation that the developers don't care. They don't care to do things that will impact performance and provide absolutely no benefit.
+1
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on December 12, 2011, 10:25:09 AM
Well, atleast with using base64_encode, you force the user to have to use a script to decode it as opposed to just reading it directly from the database.  Security should not be compromised because it impacts performance.  Anyways, I suppose this is not really a huge security issue...  You could also create a hash and base64_encode that even.  Given the time of the personal message, we could even include this into an array, with the hashed message that is base64 encoded, as well as even the id from the database for it, serialize the array, and when we unserialize we check for the time to match the time of the PM in other columns of the table or the id.

Anyways, just offering up alternatives.  If you don't like them, or think it impacts performance too much, no problem.  Just ideas is all they are.

* Sorry for getting a bit off-topic here.
Title: Re: My SMF 3.0 Dream
Post by: 青山 素子 on December 12, 2011, 11:09:41 AM
Well, atleast with using base64_encode, you force the user to have to use a script to decode it as opposed to just reading it directly from the database. 

See:
If you have enough skill to pull the right tables and display them, it's not even a hurdle to do a base64 decode on the column.


Security should not be compromised because it impacts performance.  Anyways, I suppose this is not really a huge security issue...  You could also create a hash and base64_encode that even.  Given the time of the personal message, we could even include this into an array, with the hashed message that is base64 encoded, as well as even the id from the database for it, serialize the array, and when we unserialize we check for the time to match the time of the PM in other columns of the table or the id.

Not sure what you're suggesting there. Hashes are one-way, so you couldn't get back the plaintext. The best one could do is use it to see if the message was tampered with (a checksum). However, that doesn't protect against some crazy privacy-invading admin reading the messages. Actually, it doesn't even protect against changing the messages because the modified version can simply be re-hashed and would then validate against the new hash. That, or the forum could just have that little check always return "valid", which would be a lot easier.


Anyways, just offering up alternatives.  If you don't like them, or think it impacts performance too much, no problem.  Just ideas is all they are.

I'm not sure what you're actually trying to acomplish other than make it look like something is protected when it is actually not. That's an even more dangerous state because it can make others think there is actual protection, leading to complacency.

As I noted before, while SMF tries to make it a bit more technically difficult to spy on other users, it can't ensure perfect security (nor should it, IMO) and it certainly shouldn't offer fake security.

The key here is that unless you own the whole communication channel, you can't be sure it hasn't been modified to spy on you. If you're going to try to communicate securely on a channel over which you don't have complete control, you need to use proper encryption. That means you need to be the only one with the encryption key. Giving the key to some third-party just completely breaks security.


As an example of the whole "let the server encrypt stuff" mentality going wrong, I'll make reference to Hushmail (http://en.wikipedia.org/wiki/Hushmail). They are a service that allows you to send and receive OpenPGP encrypted communications. Their old-style method was to get your private key, passphrase, and the message plaintext and then encrypt the message on their server. Note that giving them that effectively gives them everything they need to be able to decrypt any messages to or from you using that key. They actually did that and turned over plaintext copies of messages to a US Federal Court (http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/) Their newer service uses a Java Applet that does the encryption locally, but they have warned that they may be compelled by court order to send users an applet that stores and forwards them all the data.

So, yes, if you want message security you must own the entire communication chain or use encryption outside that chain and own that part. Doing silly stuff like using reversible encryption on the server, using base64 or uu encoding, or similar stunts doesn't do a thing to secure private messages.
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on December 12, 2011, 02:20:44 PM
Yeah, your right, wouldn't be secure, would just be harder to read and would impact performance a bit.  What I was suggesting with the hash, is that you see how hashes are used for file attachments in posts, well sort of the same method for this.  The hash can be stored in the database for this, within the pm table, and can be used when unserializing the array that contains the message.  But, yeah, I suppose it wouldn't make any difference, especially if everything is coming from within the database on the output of the message.
Title: Re: My SMF 3.0 Dream
Post by: 青山 素子 on December 12, 2011, 02:27:26 PM
What I was suggesting with the hash, is that you see how hashes are used for file attachments in posts, well sort of the same method for this.  The hash can be stored in the database for this, within the pm table, and can be used when unserializing the array that contains the message.

Still not sure what you're suggesting there. Are you talking about using a hash an encryption key? Also, why would you store the message as a serialized array? It's just a plain text string.


But, yeah, I suppose it wouldn't make any difference, especially if everything is coming from within the database on the output of the message.

As long as the key is in the hands of a third party, there is no security. Trying to pretend like there is some is a great way to get one's self into trouble.
Title: Re: My SMF 3.0 Dream
Post by: Joshua Dickerson on December 12, 2011, 10:37:48 PM
Xarcell, what do you mean by #25? #21 - use what works best.
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on December 12, 2011, 11:44:14 PM
What I'm saying is that SMF is using a hash to change the name of all files that get uploaded, why not do this for pm messages in the same way?  The hash can be stored in a column where the pm messages are stored or where ever, than for the message, you can make it an array...
Code: [Select]
$pm = array(
    'message' => {holds the actual message that could be base64_encoded or not},
    'id' => {id of message to match against that matches the primary key},
    'hash' => {why not store the hash in here also for checking against},
// Just some more, if you'd rather store this in there as opposed to the columns of the database for this, doesn't matter really.
    'user_from' => $user_info['id'],
    'user_to' => {ids of all the members that this message has been sent to},
);

Than just serialize this entire array and place it into the database.  Unserialize it when it is needed, and do some checking with it.

Serializing
Code: [Select]
base64_encode(serialize($pm));
Unserializing (where $row['pm'] is the serialized array from the database table)
Code: [Select]
unserialize(base64_decode($row['pm']));
Anyways, I'm not looking at SMF's pm table right now and haven't in awhile, so I'm just going from memory here.  If you are saying that using a hash is not going to help in security here, than why bother using a hash for file attachments at all?  What security does this provide other than hiding the original filename from members and from being stored on your server with that filename and ofcourse the .htaccess and index.php file that helps with this also.

Anyways, I haven't completely thought this out, I'm just throwing things out there that should be considered.  It's not my call anyways.
Title: Re: My SMF 3.0 Dream
Post by: 青山 素子 on December 13, 2011, 12:25:35 AM
What I'm saying is that SMF is using a hash to change the name of all files that get uploaded, why not do this for pm messages in the same way?  The hash can be stored in a column where the pm messages are stored or where ever, than for the message, you can make it an array...
Code: [Select]
$pm = array(
    'message' => {holds the actual message that could be base64_encoded or not},
    'id' => {id of message to match against that matches the primary key},
    'hash' => {why not store the hash in here also for checking against},
// Just some more, if you'd rather store this in there as opposed to the columns of the database for this, doesn't matter really.
    'user_from' => $user_info['id'],
    'user_to' => {ids of all the members that this message has been sent to},
);

Than just serialize this entire array and place it into the database.  Unserialize it when it is needed, and do some checking with it.

What benefit would this give you? Also, how would this affect the database calls needed to find all messages to an individual user?

Filenames are hashed to prevent collisions in filenames. For example, if two users (or even the same user did this twice) uploaded a file called image.jpg, you'd run into a collision depending on how you structure the file storage. Creating a hash with some variable data prevents this collision. You don't need this in a database table because you can make an artificial unique data column (usually called "id"). It also prevents more simplistic filename guessing games or tricks of uploading files ending in ".php" and calling directly to make them execute on the server.



If you are saying that using a hash is not going to help in security here, than why bother using a hash for file attachments at all?  What security does this provide other than hiding the original filename from members and from being stored on your server with that filename and ofcourse the .htaccess and index.php file that helps with this also.

See the above explanation. It's more about preventing filename collisions than security. The fact that it helps a bit with blind upload attacks is a nice bonus.


Anyways, I haven't completely thought this out, I'm just throwing things out there that should be considered.  It's not my call anyways.

Yeah, I don't think you're considering how the system would have to work when you start serializing internal data structures (it gets messy). Anyway, as long as the server has the key, it's trivial to decode the messages or to write some quick code that will do all the processing and present a nice list for you. Private messages are designed to offer some basic privacy from casual snooping, not complete security from a dedicated user.

It's kinda like a simple lock on a file cabinet - it keeps the basic snoops out. For those that want to get in, it's just usually a simple wafer lock that can be opened with the file on a nail clipper (http://www.youtube.com/watch?v=MLc9PkhrEWc).
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on December 13, 2011, 12:43:54 AM
Yeah, I see what you mean, and duhhh, definitely see what you mean on file attachments, argg!  Forgot that the user's id value prepends to the filename also to help with this collision of hashes that could even occur.
Title: Re: My SMF 3.0 Dream
Post by: .Vapor on February 17, 2012, 05:32:30 PM
Great ideas ! I especially like the "forum, blog, article" idea for posts / content.

+1 to almost all of them :)
Title: Re: My SMF 3.0 Dream
Post by: die2mrw007 on February 17, 2012, 06:12:43 PM
Any news on what all has been accepted for 3.0 and what all ideas has been scrapped from the list mentioned here ?
Title: Re: My SMF 3.0 Dream
Post by: Fustrate on February 17, 2012, 06:29:43 PM
We're not far enough to definitively accept/deny most of these things, but we're keeping everything in mind. Much of the list applies to aesthetics and minor tweaks instead of the major groundwork.

Don't hold me to any of this, but:

Quote
1. Yes
2. Yes
3. No
4. Yes
5. Might as well, but not a concern at this point in development
6. It'll happen in some form
7. Yes
8. Yes
9. Yes
10. There will be a way to compress js/css (I'm also looking at LESS compilers)
11. Good idea
12. Would probably be a mod/plugin
13. Yes
14. I'm not a theme designing person, no comment
15. Yes
16. Won't eliminate the post page, but we will expand quick/ajax reply
17. Yes
18. Yes
19. No comment/opinion
20. I'd like to see it
21. Yes, PNG > GIF, but I'm a bit wary of SVG. Haven't used it enough.
22. Karma won't be in the central product anymore. Calendar and Karma are bloat that should be optional.
23. CSS-wise? Yes
24. Yes
25. 3.0 will support at least Apache, Litespeed, and nginx fully.
26. Sure, why not
27. Good idea
28. Isn't that already in 2.0? I honestly haven't looked in a LONG time.
29. iirc, big guy keeps pushing for it for 2.1
30. jQuery yes, jQuery mobile no
31. Good idea
32. As I said before, no way.
33. I think that's going to be in 2.1
34. Good idea

Norv could reverse any of that, but it's what I'm aiming for at least. Knowing myself, though, I have a different opinion every week :P
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 03, 2012, 06:43:12 PM
pretty urls are pointless....

and attachments in PM is a bad idea.   If someone distributes illegal or copyrighted material via PM, this now makes the ADMIN responsible....   and the admin can not (easily) scan PMs.

Just curious how this makes the admin responsible?
Title: Re: My SMF 3.0 Dream
Post by: Kindred on April 03, 2012, 06:50:56 PM
Because, as owner/admin, you are legally responsible for the content of your site, whether you participate or not
Title: Re: My SMF 3.0 Dream
Post by: Antechinus on April 03, 2012, 06:55:44 PM
Actually I was thinking about this yesterday. It is still possible for PM's to contain illegal or unethical content even without attachments, so I'm not sure that argument against PM attachments is really a valid argument.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 03, 2012, 07:14:03 PM
Because, as owner/admin, you are legally responsible for the content of your site, whether you participate or not

Oh really.  If that was the case there would be no sites online with any kind of uploads of any kind, PM, Post Uploads or Gallery Uploads etc and no ISPs and hosting providers as well.     SOPA | PIPA did not pass btw had it then it would have been a whole new ball game in town.  This could change and let's hope it doesn't.   I just checked with my host and have chat transcripts and as I suspected I am good with my understanding on how the DMCA take down works.  It's quite simple actually.  I just need to get the DMCA instructions set up on my site.  Sorry just because we hear it on the net doesn't mean we should take it for gospel.

Thanks for responding though.

P.S. There are lot of resources on the net that explain this in much more detail than I ever could here in a few minutes.  Might be a good idea to check some out if anyone is in doubt which imo is always the best policy in situations like this or even consult an attorney but I really don't feel that is necessary in this situation.

P.S. 2  You are legally responsible to follow the steps in a DMCA take down notice that much I will say is correct.
Title: Re: My SMF 3.0 Dream
Post by: Kindred on April 03, 2012, 11:31:40 PM
I beg to differ... I have been on both sides of the responsibility issue, both as the initiator and the target...   So, yes... An admin IS responsible or everything on his site.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 12:00:09 AM
 :D  As I have let me tell you, being on both sides that is. 

You can beg to differ that is your right.  They way it works though is the uploader is still responsible for the content.  When the site is alerted the site does have responsibility as already stated actually till the site gets a DMCA the site can not legally enforce other entities copyrights only one person can do that and that is the holder or a representative of the holder.  If that was the case there would be no uploads hot linking here and I bet we can find some copyright issues here?  Yes or No?  As I said it's really quite simple the way it works.

I mean the easiest way to prove me or the way it works wrong is show us.  This would surely be the best way.  Let me post some from my point.



The U.S. Digital Millennium Copyright Act (1998) and the European E-Commerce Directive (2000) provide online intermediaries with limited statutory immunity from liability for copyright infringement. Online intermediaries hosting content that infringes copyright are not liable, so long as they do not know about it and take actions once the infringing content is brought to their attention. In U.S. law this is characterized as "safe harbor" provisions, and in European law as the "mere conduit" principle.  See here the site needs to be notified.



The enforcement of copyright is the responsibility of the copyright holder.[7] Article 50 of the Agreement on Trade-Related Aspects of Intellectual Property Rights (TRIPs) requires that signatory countries enable courts to remedy copyright infringement with injunctions and the destruction of infringing products, and award damages.[5] Copyright holders have started to demand through the ACTA trade agreement that states act to defend copyright holders' rights and enforce copyright law through active policing of copyright infringement.[8] It has also been demanded that states provide criminal sanctions for all types of copyright infringement and pursue copyright infringement through administrative procedures, rather than the judicial due process required by TRIPs.[7]  Here you can see who has the responsibility of enforcing copyright and it is not the site as the site has no idea if they person has permission from the company plus the site is not in a position to decide what is and what is not a violation just the holder or a rep of the holder can.



This is a quick run down from Wikipedia.  I am not going to spend hours finding other sources but I will wait for your sources that list the site as being responsible.

If this was even remotely close Photobucket, imageshack and youtube(just on Prince videos alone) would have already been shut down long ago?  Yes or No?
Title: Re: My SMF 3.0 Dream
Post by: Fustrate on April 04, 2012, 12:28:08 AM
It's not just a matter of copyrighted material, it's also things like child pornography. With public attachments, you have a reasonable chance of finding it yourself or having it reported, but with PM attachments they're storing the images on your server and you're none the wiser. It's easier to just not open yourself up to that in the first place than having to explain to LEOs that you didn't know it was there. Place like Youtube and imgur monitor for that stuff and are big enough that LEOs won't blame them, but none of us are.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 12:33:41 AM
It's not just a matter of copyrighted material, it's also things like child pornography. With public attachments, you have a reasonable chance of finding it yourself or having it reported, but with PM attachments they're storing the images on your server and you're none the wiser. It's easier to just not open yourself up to that in the first place than having to explain to LEOs that you didn't know it was there. Place like Youtube and imgur monitor for that stuff and are big enough that LEOs won't blame them, but none of us are.

This is an interesting discussion and hard to find good discussions on the net but the discussion is not whether or not it opens yourself up but rather who is responsible.

Child porn is another issue altogether.  However the uploader is still responsible less of course you can prove the site is knowing its going on and allowing the users to do but as I said child porn is not copyright and another issue all together.  No different than a user using webmail how many small little sites like us have people with email accounts?  So are you saying sites should only allow admin to have email through the domain?
Title: Re: My SMF 3.0 Dream
Post by: Fustrate on April 04, 2012, 12:37:56 AM
It may be another issue, but it's an issue with PM attachments. Yes, the uploader is responsible in the end, but you're going to go through quite a bit of (stuff) with law enforcement to show that you don't have any liability. The cops who deal with CP are trained not to take anyone's word.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 12:41:43 AM
It may be another issue, but it's an issue with PM attachments. Yes, the uploader is responsible in the end, but you're going to go through quite a bit of (stuff) with law enforcement to show that you don't have any liability. The cops who deal with CP are trained not to take anyone's word.

I agree to that.  However as I said in the previous post which I edited to include what I am saying here  that wasn't what the discussion was.  I agree it could be a serious pain but the uploader ultimately remains responsible. 

Still there is a due process at least in some countries anyways but yes it could be a real PITA if some dumb ass was to upload CP to PM attachments or to webmail as both are the basically the same situation and there is no difference between PM attachments and webmail.  So webmail is toast too?

Thanks for stating the pink that is what this little side discussion is truly about.
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on April 04, 2012, 01:10:45 AM
Interesting that you actually have researched this and proved this to be wrong RoCKeT-88!  Thanks!  TBH, seems to me that there were too many haters of my PM Attachments mod and those not really knowing the real truth, that the uploader is responsible for what they upload.  In any case, if this were even an issue, PM Attachments could be unapproved until they were reviewed, but than we have an issue on PERSONAL CONTENT, which is what PM Attachments are about.  I originally coded PM Attachments with all attachments within all PM able to be viewed.  A whole section was dedicated to this, but than SMF Customization Team told me that this was a security issue that PM Attachments should not be able to be viewed because they were considered personal, which makes sense (even if the only people that could view them were the FORUM ADMINISTRATORS), which are the same people that it goes to when reporting Personal Messages, but than they say that the Owner of the site is responsible for the content on the site so you can't allow it to be uploaded without some sort of reviewing of the files to be sure they are appropriate for your site.  Both of these contradict each other, cause you just can't satisfy both of these at the same time.  It's either one or the other.  And honestly, if you aren't responsible for the content on your site, or if you notify the user, while they are sending a Personal Message with an attachment, that the content may, or will, be viewed by forum administrators before it is approved, or before the actual Personal Message gets sent, than what is the problem??

Here's the problem...  A Grudge against my Mod!  The demand for it was too great...  So many people requested it, and I made it first.  Even SMF's own Customization Team members and others talked about creating it in certain topics where it was requested...  BUT NOW...  Believe it or not, they have a problem with it!  Let's try to rationalize a way to say it is not wanted without actually saying that, shall we??  Let's try and create a problem that makes sense to everyone...

Whatever...
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 01:20:34 AM
Interesting that you actually have researched this and proved this to be wrong RoCKeT-88!  Thanks!  TBH, seems to me that there were too many haters of my PM Attachments mod and those not really knowing the real truth, that the uploader is responsible for what they upload.  In any case, if this were even an issue, PM Attachments could be unapproved until they were reviewed, but than we have an issue on PERSONAL CONTENT, which is what PM Attachments are about.  I originally coded PM Attachments with all attachments within all PM able to be viewed.  A whole section was dedicated to this, but than SMF Customization Team told me that this was a security issue that PM Attachments should not be able to be viewed because they were considered personal, which makes sense (even if the only people that could view them were the FORUM ADMINISTRATORS), which are the same people that it goes to when reporting Personal Messages, but than they say that the Owner of the site is responsible for the content on the site so you can't allow it to be uploaded without some sort of reviewing of the files to be sure they are appropriate for your site.  Both of these contradict each other, cause you just can't satisfy both of these at the same time.  It's either one or the other.  And honestly, if you aren't responsible for the content on your site, or if you notify the user, while they are sending a Personal Message with an attachment, that the content may, or will, be viewed by forum administrators before it is approved, or before the actual Personal Message gets sent, than what is the problem??

Here's the problem...  A Grudge against my Mod!  The demand for it was too great...  So many people requested it, and I made it first.  Even SMF's own Customization Team members and others talked about creating it in certain topics where it was requested...  BUT NOW...  Believe it or not, they have a problem with it!  Let's try to rationalize a way to say it is not wanted without actually saying that, shall we??  Let's try and create a problem that makes sense to everyone...

Whatever...

I have no idea about what has been going on with this mod or feature to be honest it just happened to catch my eye and I felt like a good discussion about it nothing more nothing less.  I just though it was kinda odd they had anti SOPA PIPA avatar and what they were saying would have been true if those would have passed.  I said luckily they didn't as being responsible for someone else s wrong doing makes absolutely no sense now does it?
Title: Re: My SMF 3.0 Dream
Post by: 青山 素子 on April 04, 2012, 01:34:38 AM
that the uploader is responsible for what they upload.

True, but given the recent developments in the "take down first, figure out guilt later" actions going on, even if the uploader will be responsible, the site owner will have quite a fight while their website is down. Also, the owner will have to prove that they had no knowledge of the file activity and probably undergo investigations.


In any case, if this were even an issue, PM Attachments could be unapproved until they were reviewed, but than we have an issue on PERSONAL CONTENT, which is what PM Attachments are about.

Yep, having to do the whole approval thing and active monitoring means you lose whatever safe harbor status exists.


but than SMF Customization Team told me that this was a security issue that PM Attachments should not be able to be viewed because they were considered personal, which makes sense (even if the only people that could view them were the FORUM ADMINISTRATORS), which are the same people that it goes to when reporting Personal Messages,

Yes, but reports are actively sent by one of the parties to the messages, not proactively viewed by those administrators.


but than they say that the Owner of the site is responsible for the content on the site so you can't allow it to be uploaded without some sort of reviewing of the files to be sure they are appropriate for your site.  Both of these contradict each other, cause you just can't satisfy both of these at the same time. 

Nope, you can't. That doesn't mean that they are contradictory. PMs should be as private as possible, and administrators will have problems if a file in those has some legal issues.

PMs and their contents should be private unless one of the parties chooses otherwise. Attachments use up space and should have the ability to be reviewed if needed. Therefore, attachments in PMs is a bad idea.


Here's the problem...  A Grudge against my Mod!  The demand for it was too great...  So many people requested it, and I made it first.  Even SMF's own Customization Team members and others talked about creating it in certain topics where it was requested...  BUT NOW...  Believe it or not, they have a problem with it!  Let's try to rationalize a way to say it is not wanted without actually saying that, shall we??  Let's try and create a problem that we can pass as fact to everyone.

I honestly don't think it's about you. Besides, you can always post your modification elsewhere. It's not like you're being prevented from doing it anywhere.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 01:41:22 AM
that the uploader is responsible for what they upload.

True, but given the recent developments in the "take down first, figure out guilt later" actions going on, even if the uploader will be responsible, the site owner will have quite a fight while their website is down. Also, the owner will have to prove that they had no knowledge of the file activity and probably undergo investigations.



In any case, if this were even an issue, PM Attachments could be unapproved until they were reviewed, but than we have an issue on PERSONAL CONTENT, which is what PM Attachments are about.

Yep, having to do the whole approval thing and active monitoring means you lose whatever safe harbor status exists.


This would only apply in the CP not copyright|trademark two different situations and rules.  If you discover CP you don't wait for a DMCA take notice lol you document it, SS, get IPs and anything else, take it down and contact authorities and the host!  This is not rocket science.

The site is not responsible for trying to figure out other peoples copy right.   It's not a hard concept the info is readily available. 

Have to stop confusing CP with ® when a site is responsible for removing content
Title: Re: My SMF 3.0 Dream
Post by: Fustrate on April 04, 2012, 01:50:12 AM
But how are you supposed to know about it when it's in a private message? If two people are using your forum to share CP, that's going to cause trouble for you if anyone finds out, there's no way around it.

Private messages should be private, otherwise the conversation might as well just be in a public board. Breaking the privacy of PMs is not something we'll build into SMF.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 01:52:23 AM
But how are you supposed to know about it when it's in a private message? If two people are using your forum to share CP, that's going to cause trouble for you if anyone finds out, there's no way around it.

Private messages should be private, otherwise the conversation might as well just be in a public board. Breaking the privacy of PMs is not something we'll build into SMF.

Then your not responsible obviously as stated before by you and I, and I agreed it would be a hassle but really have to wonder what kind of board people are running to have to worry so much about this and what is on their systems, just thinking here.  I think 99.9999999% of admins could easily show they weren't involved with what their  forum users were doing.  Just like webmail.  So never got answer  to this question so webmail is out too?  If this was true YahooMail! would already be shut down.

Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 01:56:52 AM
I agree admins should not be approving PM btw.  Be like Yahoo checking every webmail message.
Title: Re: My SMF 3.0 Dream
Post by: Fustrate on April 04, 2012, 02:00:27 AM
And when one of those people gets raided by the authorities, their computer is searched, and your website turns out to be a hub for pedophiles? Yes, it's an overly dramatic scenario, but it can happen. We'd rather not put a feature that can be abused into the vanilla distribution of our product, but that doesn't mean you can't distribute or install a mod or plugin which adds that feature.

In the end, it comes down to what the developers are willing to add to SMF, and this is just one of those things that we're not going to do.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 02:03:24 AM
And when one of those people gets raided by the authorities, their computer is searched, and your website turns out to be a hub for pedophiles? Yes, it's an overly dramatic scenario, but it can happen. We'd rather not put a feature that can be abused into the vanilla distribution of our product, but that doesn't mean you can't distribute or install a mod or plugin which adds that feature.

In the end, it comes down to what the developers are willing to add to SMF, and this is just one of those things that we're not going to do.


I think that scenario is out of the scope of the discussion, clearly.  I am still waiting to hear about webmail just for fun.  Does the newletter feature allow attachments?  Don't really know right off hand but could that be a similar issue?

I think it would be easier to just say were just not doing this tbh as to try to pedal this idea imo but I am just user not a SMF admin and my 2 cents dont go too far here.  I have no beef in it really as I am not interested in PM attachments for my forum I was just disputing who was going to be on the spot for uploads.  This is like saying Verizon should not sell answering machines cause a user might leave messages about CP.  However SMF ultimately decides what features to include end of story, take it or leave it.  That is not what I was really discussing but we can do that too lol


Sorry for many edits as I am on the laptop and in bed and my typing skills are not of a secretary lol
Title: Re: My SMF 3.0 Dream
Post by: 青山 素子 on April 04, 2012, 02:11:05 AM
I think that scenario is out of the scope of the discussion, clearly.  I am still waiting to hear about webmail.

If you are hosting mailboxes for people and those people exchange illegal content using it, or just violating copyright using it, you could still run into trouble. Yes, there is the whole "safe harbor" thing and other defenses, but you might still be subject to legal issues of which you may not want.

Also, it wouldn't be too hard to be a pain and use PM attachments to eat up disk space to mess with the owner. Since those are PM attachments, you couldn't just go and clean them out like you could with public attachments.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 02:12:29 AM
I think that scenario is out of the scope of the discussion, clearly.  I am still waiting to hear about webmail.

If you are hosting mailboxes for people and those people exchange illegal content using it, or just violating copyright using it, you could still run into trouble. Yes, there is the whole "safe harbor" thing and other defenses, but you might still be subject to legal issues of which you may not want.

Also, it wouldn't be too hard to be a pain and use PM attachments to eat up disk space to mess with the owner. Since those are PM attachments, you couldn't just go and clean them out like you could with public attachments.

I am not sure how many times I have to say I agree the headaches are there or could be.  I have agreed to that numerous times already.  Ultimately that is the site admins choice. 

Disk space argument I get totally but that is the site admins problem no one elses.
Title: Re: My SMF 3.0 Dream
Post by: Antechinus on April 04, 2012, 02:39:14 AM
I think that scenario is out of the scope of the discussion, clearly.  I am still waiting to hear about webmail.

If you are hosting mailboxes for people and those people exchange illegal content using it, or just violating copyright using it, you could still run into trouble. Yes, there is the whole "safe harbor" thing and other defenses, but you might still be subject to legal issues of which you may not want.

Also, it wouldn't be too hard to be a pain and use PM attachments to eat up disk space to mess with the owner. Since those are PM attachments, you couldn't just go and clean them out like you could with public attachments.

Actually you could, even without viewing them. You simply make it a site policy that if storage space becomes an issue, any and all attachments may be subject to removal.

Ok, let's take the current PM system. Using that on a vanilla installation, a person who is so inclined can already do the following:

1/ Use the bbc img tags to exchange pictures of anything, including CP or snuff.

2/ Exchange links to illegal downloads.

3/ Engage in grooming and/or sexual harrassment of minors.

4/ Exchange proprietary code.

5/ Exchange details of hacks and other malware.

I could go on with more examples, but I'm sure the point is clear by now. As I said, I have been thinking about this lately, and I'm not convinced the old arguments against PM attachments really hold up to scrutiny.
Title: Re: My SMF 3.0 Dream
Post by: 青山 素子 on April 04, 2012, 02:39:37 AM
Then see about that modification that was mentioned earlier. The author might be fine with sending you a copy.

Remember that just because SMF isn't as bloated as you want doesn't mean you can make it that way.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 02:41:56 AM
I think that scenario is out of the scope of the discussion, clearly.  I am still waiting to hear about webmail.

If you are hosting mailboxes for people and those people exchange illegal content using it, or just violating copyright using it, you could still run into trouble. Yes, there is the whole "safe harbor" thing and other defenses, but you might still be subject to legal issues of which you may not want.

Also, it wouldn't be too hard to be a pain and use PM attachments to eat up disk space to mess with the owner. Since those are PM attachments, you couldn't just go and clean them out like you could with public attachments.

Actually you could, even without viewing them. You simply make it a site policy that if storage space becomes an issue, any and all attachments may be subject to removal.

Ok, let's take the current PM system. Using that on a vanilla installation, a person who is so inclined can already do the following:

1/ Use the bbc img tags to exchange pictures of anything, including CP or snuff.

2/ Exchange links to illegal downloads.

3/ Engage in grooming and/or sexual harrassment of minors.

4/ Exchange proprietary code.

5/ Exchange details of hacks and other malware.

I could go on with more examples, but I'm sure the point is clear by now. As I said, I have been thinking about this lately, and I'm not convinced the old arguments against PM attachments really hold up to scrutiny.

Very true great post.

Right why I said just go with were not doing it get over it~  Solves all this!  LOL
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 02:42:24 AM
Then see about that modification that was mentioned earlier. The author might be fine with sending you a copy.

Remember that just because SMF isn't as bloated as you want doesn't mean you can make it that way.

LOL Also very true and a good funny post~
Title: Re: My SMF 3.0 Dream
Post by: Antechinus on April 04, 2012, 02:55:42 AM
Personally I'd like the option of PM attachments sometimes, but I wouldn't make it available to any and all members who just happened to register. I'd be limiting it to a well-trusted group only.

This doesn't mean I'm going to jump up and down and demand it be a default feature. It's just something I've been considering as a possible addition to a site I run.
Title: Re: My SMF 3.0 Dream
Post by: RoCKeT-88 on April 04, 2012, 03:00:14 AM
Personally I'd like the option of PM attachments sometimes, but I wouldn't make it available to any and all members who just happened to register. I'd be limiting it to a well-trusted group only.

This doesn't mean I'm going to jump up and down and demand it be a default feature. It's just something I've been considering as a possible addition to a site I run.

I think it's safe to assume if so it will be a mod.  I understand this concept like if admins could only have the option.
Title: Re: My SMF 3.0 Dream
Post by: SoLoGHoST on April 04, 2012, 04:50:58 PM
Also, it wouldn't be too hard to be a pain and use PM attachments to eat up disk space to mess with the owner. Since those are PM attachments, you couldn't just go and clean them out like you could with public attachments.

Wrong!  You can clean them out the same way and much more.  I already provided tons of pruning options in the SMF Admin for my PM Attachments Mod.  You can set a maximum disk usuage storage space on them.  You can prune them by member name sent to or sent from, their age, how many views/downloads the attachments received, and many more pruning options.

But, like RoCKeT-88 stated, just say that you won't allow this to be part of SMF.  That makes more sense to me, rather than trying to rationalize why you won't make it a part of SMF...

Cheers :)
Title: Re: My SMF 3.0 Dream
Post by: Fustrate on April 04, 2012, 04:54:31 PM
We've both rationalized it to ourselves and said we won't make it a part of SMF, so we've covered all the bases :)
Title: Re: My SMF 3.0 Dream
Post by: OCJ on April 05, 2012, 03:11:59 AM
Search function does not let people know they are searching in the section they are in and not site-wide. I would even consider this equal to a bug.

Laguages install automatically but on most templates the language switcher doesnt - these days no other software is as bad as SMF in this respect. Manual edits to template files to include function calls should not be necessary.

Should be a pruning feature for private messages. At the moment there isnt even a mod to do this but it is standard on many boards. Another pile of garbage building up.



4.| Add a BBC manager and a Menu Manager.

Agree - Menu manager needed. Most SMF portals do not have this unfortunately.


6.| Remove most of the profile fields in profiles and let the custom profile fields do the work. If the admin wants them, he can create them.

Agree, and all field types should be searchable - not just the text fields.



22.| Scrap karma system for users and add like/dislike system based on posts.

Agree, Karma - outdated, let it go.



24.| Profiles need a make-over, add more information and ditch the old YaBB look. Be sure to add page views a profile, and show what the user is currently viewing.
Agree, they dont look very interesting.


26.| Allow multiple polls per topic.
Agree, waste of time adding a topic for every poll.


Title: Re: My SMF 3.0 Dream
Post by: mr.Curiosity on April 10, 2012, 02:56:37 AM
A lot of great ideas,well done
Title: Re: My SMF 3.0 Dream
Post by: Tomy Tran on June 24, 2012, 08:37:06 PM
Good morning,

I have seen some forums built by XenForo recently. Since that time I dont know is there an accidently but I feel that our new applied modifications is reducing. We have new 9 mods through 2 months, any way, I visits some forums by XenForo and Xen is really pretty, and I think SMF should come up to 3.0 very quickly and should have some utilities like in XenF such Gravatar intergrater, consider to use fb, g+, so.cl, twitter or any new social networks appears later for user's profile. Search by google or siteself is available and Google Analytics is in Core 3.0 this should have good bridges to Joomla base.

Thanks.
Title: Re: My SMF 3.0 Dream
Post by: Arantor on June 24, 2012, 08:40:42 PM
Given what has been stated previously about SMF 3.0 and smCore, it isn't going to be for at least another year, possibly even more before SMF 3.0 as such emerges into something that could be called stable.

I would note that adding social networks to the profile is very easy to do through custom fields should one be so inclined.

As for search with Google, I couldn't possibly encourage that. There are privacy implications to this that I'm certainly not comfortable with and would encourage all forum owners who use such things to be very mindful of user privacy and the implicit sharing of that data with Google, primarily for Google's benefit in being able to sell more expensive ads.