Kick-off Discussion: Existing Forum Temperature Check + Criticism

[dewdeded]

You have to search on front page to get all results.

On subpage on results in this sub.

[1713960622]

1713960622

[1713960622]

1713960622

[1713960622]

1713960622

[dogechode]

I know, I still get wacky results. Many others have made similar complaints. The forum search is fundamentally broken IMO. I do not have these types of issues on other forums.

[R2D221]

You have to search on front page to get all results.

On subpage on results in this sub.

That's not obvious at all. I learned it by trial and error.
The search bar appears on the top, before the current subforum title. So I expect it to search everything.

[tysat]

Users should have the option to upload a GPG public key that the forum uses to encrypt all notification emails.

Alternately or in addition to this, the forum should have native Bitmessage capability. This means letting users register with Bitmessage addresses and sending notifications through the Bitmessage network. Note that routing the notification through a honeypot gateway like bitmessage.ch doesn't count because the primary purpose of Bitmessage is to not have monitoring chokepoints with access to plaintext.

This is a toss-up. Technically we can enable the option without a problem and sensitive info like password reset links and things of the like can be sent with GPG if the users opt into it.

What's the toss-up?

I think the option to GPG encrypt all messages from the forum is a great idea.

[dogechode]

Also, personally, when I was new to the forum I found the constant "you must wait 180 seconds to do that" messages extremely annoying. There must be a better way to combat spam... Other forums don't do this. It seemed to happen almost every time I tried to post or reply, even when 3 minutes certainly seemed to have passed since my last post.

[taesup]

Users should have the option to upload a GPG public key that the forum uses to encrypt all notification emails.

Alternately or in addition to this, the forum should have native Bitmessage capability. This means letting users register with Bitmessage addresses and sending notifications through the Bitmessage network. Note that routing the notification through a honeypot gateway like bitmessage.ch doesn't count because the primary purpose of Bitmessage is to not have monitoring chokepoints with access to plaintext.

This is a toss-up. Technically we can enable the option without a problem and sensitive info like password reset links and things of the like can be sent with GPG if the users opt into it.

What's the toss-up?

I think the option to GPG encrypt all messages from the forum is a great idea.

GPG is a CPU intensive process. In most cases, this is not an issue because either messages are small or they are infrequent. But given the right circumstances, it could bog down the server and could be used as an attack vector much like DDOS or could even be paired with it (we need to make sure this is not possible). We have a lot of other features lined up that could be upsteam dependencies and we need to make sure that in all cases, the server is still responsive.

Let's take the email/GPG use case for example, if an email needed to be sent out to the entire user base. That email would have to be encrypted once per user and then sent out (Given everyone was using GPG). If there are (I'm making this number up) 100,000 users... Can you see how much work that would be for the CPUs? This would be on top of serving those same 100,000 user the forum as well. Now imagine if that email really didn't have anything important to say. That's a lot of work for really nothing. But what if the email did contain sensitive information? There are ways to mitigate the CPU issue by locking it down to a few or just one core but that comes with its own trade offs. The speed at which the emails are being sent out may be drastically lower. If the email isn't time-sensitive but contains sensitive information, this is fine. But what if a system wide breach of the DB were to occur and all user's login/pass were compromised. A time-sensitive and possibly information sensitive email needs to go out...

I could go on and on and keep playing what ifs. Each what if (corner case) does have a solution but some of them require that GPG is not universally used on all messages for the sake of speed. Which means more coding to ensure that logic is in place. Also, if none of the features run into issues like above then it's clearly a good idea to use GPG on everything.

This is why the idea of GPG on all communications is a toss up. It's a great idea and we'd love to implement it, but due to the nature of GPG being CPU intensive, we may need figure out a solution if two features align against each other. But since not all the forum features have been solidified, we can't make a firm decision on it right now. That's just the nature of software development.

[gweedo]

Users should have the option to upload a GPG public key that the forum uses to encrypt all notification emails.

Alternately or in addition to this, the forum should have native Bitmessage capability. This means letting users register with Bitmessage addresses and sending notifications through the Bitmessage network. Note that routing the notification through a honeypot gateway like bitmessage.ch doesn't count because the primary purpose of Bitmessage is to not have monitoring chokepoints with access to plaintext.

This is a toss-up. Technically we can enable the option without a problem and sensitive info like password reset links and things of the like can be sent with GPG if the users opt into it.

What's the toss-up?

I think the option to GPG encrypt all messages from the forum is a great idea.

GPG is a CPU intensive process. In most cases, this is not an issue because either messages are small or they are infrequent. But given the right circumstances, it could bog down the server and could be used as an attack vector much like DDOS or could even be paired with it (we need to make sure this is not possible). We have a lot of other features lined up that could be upsteam dependencies and we need to make sure that in all cases, the server is still responsive.

Let's take the email/GPG use case for example, if an email needed to be sent out to the entire user base. That email would have to be encrypted once per user and then sent out (Given everyone was using GPG). If there are (I'm making this number up) 100,000 users... Can you see how much work that would be for the CPUs? This would be on top of serving those same 100,000 user the forum as well. Now imagine if that email really didn't have anything important to say. That's a lot of work for really nothing. But what if the email did contain sensitive information? There are ways to mitigate the CPU issue by locking it down to a few or just one core but that comes with its own trade offs. The speed at which the emails are being sent out may be drastically lower. If the email isn't time-sensitive but contains sensitive information, this is fine. But what if a system wide breach of the DB were to occur and all user's login/pass were compromised. A time-sensitive and possibly information sensitive email needs to go out...

I could go on and on and keep playing what ifs. Each what if (corner case) does have a solution but some of them require that GPG is not universally used on all messages for the sake of speed. Which means more coding to ensure that logic is in place. Also, if none of the features run into issues like above then it's clearly a good idea to use GPG on everything.

This is why the idea of GPG on all communications is a toss up. It's a great idea and we'd love to implement it, but due to the nature of GPG being CPU intensive, we may need figure out a solution if two features align against each other. But since not all the forum features have been solidified, we can't make a firm decision on it right now. That's just the nature of software development.

Or why doesn't the forum move the mail server off the web server, then BINGO who cares how long it takes because now it is off the web server. Can we just use our heads a little bit and problem solve.

[augustocroppo]

This is why the idea of GPG on all communications is a toss up. It's a great idea and we'd love to implement it, but due to the nature of GPG being CPU intensive, we may need figure out a solution if two features align against each other. But since not all the forum features have been solidified, we can't make a firm decision on it right now. That's just the nature of software development.

LoL

Really? Tell me, which algorithm is not "CPU intensive"?

Oh dear, you guys are just pathetic... Yet another demonstration of incompetence for what you were massively paid to do.

EDIT: By the way, dear forum users, be careful to not open too many tabs in your browser with HTTPS loaded pages, it is very "CPU intensive", your computer could explode.

[freedomno1]

The search is weird. Many times I'll use the forum search to look for something and it either returns many erroneous results, or 0 results, then I Google the same exact string and the first result is a relevant thread on this forum lol.

It is a bit weird I forgot where but there is a suggestion to use google search instead lol
Or was

[taesup]

Or why doesn't the forum move the mail server off the web server, then BINGO who cares how long it takes because now it is off the web server. Can we just use our heads a little bit and problem solve.

This only fixes one of the problems I listed, which is the mail server bogging down the web server. But it does not fix any of the other issues such as getting all the email out in a time-sensitive manner.

[gweedo]

Or why doesn't the forum move the mail server off the web server, then BINGO who cares how long it takes because now it is off the web server. Can we just use our heads a little bit and problem solve.

This only fixes one of the problems I listed, which is the mail server bogging down the web server. But it does not fix any of the other issues such as getting all the email out in a time-sensitive manner.

How does it not fix that? If you have a mail server with a decent amount of cores it can use all the cores and process many at one time, I would say it should able to process about 500 emails at one time. You don't have really care about getting mail so that eliminates that processing. And if you really cared you can build your own really slim smtp server.

[taesup]

LoL

Really? Tell me, which algorithm is not "CPU intensive"?

Oh dear, you guys are just pathetic... Yet another demonstration of incompetence for what you were massively paid to do.

EDIT: By the way, dear forum users, be careful to not open too many tabs in your browser with HTTPS loaded pages, it is very "CPU intensive", your computer could explode.

Actually most video games are GPU intensive and not CPU intensive, also any time you use a reasonably well written OpenGPL webpage, also CSS3 transform are all offloaded to the video card, also massive batch processing algorithms (CUDA) often make use of the GPU instead of the CPU because of the nature of the algorithm. Should I go on?

The point you've missed is that the intensive CPU processing, in this fictional scenario, all takes place on the server and not distributed on the client side.

[Wangbus]

Users should have the option to upload a GPG public key that the forum uses to encrypt all notification emails.

Alternately or in addition to this, the forum should have native Bitmessage capability. This means letting users register with Bitmessage addresses and sending notifications through the Bitmessage network. Note that routing the notification through a honeypot gateway like bitmessage.ch doesn't count because the primary purpose of Bitmessage is to not have monitoring chokepoints with access to plaintext.

This is a toss-up. Technically we can enable the option without a problem and sensitive info like password reset links and things of the like can be sent with GPG if the users opt into it.

What's the toss-up?

I think the option to GPG encrypt all messages from the forum is a great idea.

I agree, but it's more of a usability issue. I think users can and will get their GPG keys screwed up. We will try to put this feature in though. Just need to think about how to orchestrate it.

[Wangbus]

Initial responses have been decent. I will be posting interesting posts to its own topic for further discussion after this week.

[hurricandave]

I didn't get any support on this comment before but will try again.
Could you please modify the watchlist such that a user can select from a list, threads that they want to return to (view) regardless if it has had a new post since their last visit.

[augustocroppo]

LoL

Really? Tell me, which algorithm is not "CPU intensive"?

Oh dear, you guys are just pathetic... Yet another demonstration of incompetence for what you were massively paid to do.

EDIT: By the way, dear forum users, be careful to not open too many tabs in your browser with HTTPS loaded pages, it is very "CPU intensive", your computer could explode.

Actually most video games are GPU intensive and not CPU intensive, also any time you use a reasonably well written OpenGPL webpage, also CSS3 transform are all offloaded to the video card, also massive batch processing algorithms (CUDA) often make use of the GPU instead of the CPU because of the nature of the algorithm. Should I go on?

"GPU" is also a "CPU". It is just a different name for the same concept. All algorithms use a considerable amount of processing power, whatever this power come from the main processor (CPU) or from a secondary processor (GPU).

The point you've missed is that the intensive CPU processing, in this fictional scenario, all takes place on the server and not distributed on the client side.

No, this is the point you missed. You were paid $350000 (+ $750000) to develop a software from the scratch, but you cannot even implement GPG in the development because it is "CPU intensive".

LoL

If every developer was incompetent like you, we would not have this amazing "CPU intensive" algorithms to shrink the size of data being transmitted among electronic devices.

[davidpbrown]

Perhaps an option to highlight threads created by established members or a way for user to suggest a threshold, below which new threads are hidden to them. Obviously, ignoring individual users works but I wonder the difference that just excluding new threads from those with less that X activity might be helpful. The current icons on the left of threads suggesting ?hot topics, aren't useful - perhaps those could highlight heros; friends; and users with less that 8 digit IDs  

[Rawted]

Augusto Croppo is spot on. This is pathetic.

[Wangbus]

Everything going through GPG might be a possibility. I'd like to explore these options once we get the initial migration off the ground.

Although supporting the migration of this forum is the top priority, keep in mind that this is a separate product that's open sourced. We have a team that will funnel contributions from the public when the system becomes more stable.

[gweedo]

We have a team that will funnel contributions from the public when the system becomes more stable.

Why not make it transparent now so we can see how much work by commits are being done? How do we even know you started? I mean it is taking this long to do an ad auction system, that could be done in a week, I can't imagine the forum is going to be taking a year, it is looking like two years.