Bitcoin Forum
September 25, 2018, 08:19:43 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Kick-off Discussion: Existing Forum Temperature Check + Criticism  (Read 4073 times)
dogechode
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile
March 27, 2014, 02:59:46 PM
 #21

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.
1537906783
Hero Member
*
Offline Offline

Posts: 1537906783

View Profile Personal Message (Offline)

Ignore
1537906783
Reply with quote  #2

1537906783
Report to moderator
Einax Airdrops and Bounties made easy! List your ERC-20 token
FREE
ETH markets launching soon!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537906783
Hero Member
*
Offline Offline

Posts: 1537906783

View Profile Personal Message (Offline)

Ignore
1537906783
Reply with quote  #2

1537906783
Report to moderator
1537906783
Hero Member
*
Offline Offline

Posts: 1537906783

View Profile Personal Message (Offline)

Ignore
1537906783
Reply with quote  #2

1537906783
Report to moderator
dewdeded
Legendary
*
Offline Offline

Activity: 1190
Merit: 1011


Monero Evangelist


View Profile WWW
March 27, 2014, 04:01:51 PM
 #22

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

On subpage on results in this sub.
dogechode
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile
March 27, 2014, 05:26:11 PM
 #23

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
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
March 27, 2014, 05:32:20 PM
 #24

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.

An economy based on endless growth is unsustainable.
tysat
Legendary
*
Offline Offline

Activity: 966
Merit: 1001


Keep it real


View Profile
March 27, 2014, 06:28:34 PM
 #25

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
Full Member
***
Offline Offline

Activity: 182
Merit: 100


View Profile
March 27, 2014, 07:17:57 PM
 #26

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
Member
**
Offline Offline

Activity: 99
Merit: 10


View Profile
March 27, 2014, 08:21:08 PM
 #27

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.

I am a Epochtalk (New Forum Software) Developer.
gweedo
Legendary
*
Offline Offline

Activity: 1246
Merit: 1000


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
March 27, 2014, 09:33:41 PM
 #28

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.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
augustocroppo
VIP
Hero Member
*
Offline Offline

Activity: 756
Merit: 500


View Profile
March 28, 2014, 12:43:43 AM
 #29

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
Legendary
*
Offline Offline

Activity: 1526
Merit: 1023


Activity: 9001 == OP


View Profile WWW
March 28, 2014, 01:00:36 AM
 #30

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

BITEX
            ███     ███     ███
              ███     ███     ███
                ███     ███     ███
                  ███     ███     ███
                    ███     ███     ███
                      ███     ███     ███
                        ███     ███     ███
                          ███     ███     ███
                            ███     ███     ███
                              ███     ███     ███
                            ███     ███     ███
                          ███     ███     ███
                        ███     ███     ███
                      ███     ███     ███
                    ███     ███     ███
                  ███     ███     ███
                ███     ███     ███
              ███     ███     ███
            ███     ███     ███

The First Locally-Embedded, Yet Global, Crypto-Bank
TELEGRAM    FACEBOOK   TWITTER    YOUTUBE    LINE

                  ███     ███     ███
                ███     ███     ███
              ███     ███     ███
            ███     ███     ███
          ███     ███     ███
        ███     ███     ███
      ███     ███     ███
    ███     ███     ███
  ███     ███     ███
███     ███     ███
  ███     ███     ███
    ███     ███     ███
      ███     ███     ███
        ███     ███     ███
          ███     ███     ███
            ███     ███     ███
              ███     ███     ███
               ███     ███     ███
                 ███     ███     ███

WHITEPAPER | ANN
50% discount pre-ICO NOW!
taesup
Member
**
Offline Offline

Activity: 99
Merit: 10


View Profile
March 28, 2014, 01:38:16 AM
 #31

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.

I am a Epochtalk (New Forum Software) Developer.
gweedo
Legendary
*
Offline Offline

Activity: 1246
Merit: 1000


Java, PHP, HTML/CSS Programmer for Hire!


View Profile WWW
March 28, 2014, 01:42:53 AM
 #32

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.

Want to earn 2500 SATOSHIS per hour? Come Chat and Chill in https://goseemybits.com/lobby
taesup
Member
**
Offline Offline

Activity: 99
Merit: 10


View Profile
March 28, 2014, 01:45:10 AM
 #33

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.

I am a Epochtalk (New Forum Software) Developer.
Wangbus
Staff
Member
**
Offline Offline

Activity: 110
Merit: 11

Principal at Slickage


View Profile
March 28, 2014, 11:04:54 AM
 #34

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
Staff
Member
**
Offline Offline

Activity: 110
Merit: 11

Principal at Slickage


View Profile
March 28, 2014, 11:08:57 AM
 #35

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

Activity: 945
Merit: 1000



View Profile
March 28, 2014, 11:31:21 AM
 #36

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
VIP
Hero Member
*
Offline Offline

Activity: 756
Merit: 500


View Profile
March 28, 2014, 12:27:56 PM
 #37

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

Quote
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
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


Vires in Numeris


View Profile WWW
March 28, 2014, 02:46:58 PM
 #38

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  Cool

฿://1CBxm54Ah5hiYxiUtD7JGYRXykT5Z6ZuMc
Rawted
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500



View Profile
March 28, 2014, 04:48:19 PM
 #39

Augusto Croppo is spot on. This is pathetic.
Wangbus
Staff
Member
**
Offline Offline

Activity: 110
Merit: 11

Principal at Slickage


View Profile
March 28, 2014, 09:40:15 PM
 #40

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.
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!