59 packages used in Epochtalk, why ?

[Bitcoin_BOy$]

Hello everyone,
Epochtalk has been in development status for many years (Millions of dollars has been sent to developers).

Rather than talking about why it's late or when it will come, I would ask why is 59 packages really needed ?
maintenance of such project would be a hell for developers and this means developers will be rent forever to keep the new forum working.

Almost every user in this forum like the classic design, they need new features. don't say that PHP is too old to run a forum, Facebook is built on top of PHP
fast and has billions of users.

development of such project using PHP wouldn't cost you a 15 000 dollars at max, and it will be super fast and secure, same for python.

So today, I will ask theymos to have the epochtalk project paused and not cancelled.
Focus on security update for the current forum, add new features.

go and search 3 expert PHP developers & 2 frontend developers for a 3k per month each for and that's a real solution.

[mprep]

Rather than talking about why it's late or when it will come, I would ask why is 59 packages really needed ?

Since reusing code written by other people (instead of reinventing the wheel) is a common thing in software development? I'm not quite sure what's strange about it.

maintenance of such project would be a hell for developers and this means developers will be rent forever to keep the new forum working.

If they aren't blindly trusting random NPM packages and actually review them before using them in the project, maintenance will only be a slightly more difficult at worst and much easier at best.

Almost every user in this forum like the classic design,

That's debatable. From what I've personally witnessed, there are quite a few new or potential users who get turned off by the design. Many of those that stick around usually like it due to its familiarity, rather than actual aesthetic beauty. While I'm not particularly bothered by it, it'd be nice to have something a bit more modern (or at least an option to choose).

don't say that PHP is too old to run a forum, Facebook is built on top of PHP
fast and has billions of users.

Facebook's performance is not due it's usage of PHP - it's in spite of it. Looking at https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites, Facebook is powered by much more than PHP. And even then, they aren't even using the vanilla PHP runtime - the wiki mentions HHVM, which I assume is referring to https://hhvm.com/. On top of that, Facebook has the budget to hire engineers that can squeeze out every little bit of performance from whatever tech they're using.

While a bit anecdotal, I've had the personal displeasure of using PHP. While it was only for a few small personal projects, it was enough for me to never use it again. Then again, choosing Node.Js to develop forum software that's supposed to scale IMO was a bit of a questionable decision.

development of such project using PHP wouldn't cost you a 15 000 dollars at max, and it will be super fast and secure, same for python.

You get what you pay for. If you paid a couple of PHP freelancers 15K to develop a new forum software from scratch, at best you'd get a somewhat functional but basic result. It will not be nearly secure enough to withstand the constant poking and prodding that Bitcointalk receives on a daily basis (see all the site-wide hacks Bitcointalk suffered throughout the years) nor will it be more performant than what we currently have.

While I love Python, it'd also be pretty painful trying to scale it to the traffic that Bitcointalk receives on the daily. Interpreted languages just weren't meant for building scalable web applications.

Focus on security update for the current forum, add new features.

That's what theymos is doing already.

go and search 3 expert PHP developers & 2 frontend developers for a 3 10-20k per month each for and that's a real solution.

FTFY. If you pay sweatshop salaries, you get sweatshop results. Outsourcing development of security and performance critical software to a couple no-name random freelancers across the ocean doesn's seem like a smart solution to me.

[mikeywith]

go and search 3 expert PHP developers & 2 frontend developers for a 3k per month each for and that's a real solution.

i am not aware of any real expert PHP developers that will accept 3k per month , neither have a ability to build such a project from zero in a month period.

[Initscri]

Hello everyone,
Epochtalk has been in development status for many years (Millions of dollars has been sent to developers).

Rather than talking about why it's late or when it will come, I would ask why is 59 packages really needed ?
maintenance of such project would be a hell for developers and this means developers will be rent forever to keep the new forum working.

Almost every user in this forum like the classic design, they need new features. don't say that PHP is too old to run a forum, Facebook is built on top of PHP
fast and has billions of users.

development of such project using PHP wouldn't cost you a 15 000 dollars at max, and it will be super fast and secure, same for python.

So today, I will ask theymos to have the epochtalk project paused and not cancelled.
Focus on security update for the current forum, add new features.

go and search 3 expert PHP developers & 2 frontend developers for a 3k per month each for and that's a real solution.

$3k for Freelance programmers per month is a bit of a stretch. You may find that in certain countries. Not to mention, this is a large scale project, you would need someone overseeing the entire project (PMs) etc.

You're kind of defeating the purpose of your argument. You're suggesting the project can be completed quickly but then questioning why it's using 57 packages.  I can almost guarantee anyone being paid $3k per month isn't going to be "reinventing the wheel" by completely writing new packages.

I do somewhat agree with your defence of PHP (it's definitely gotten better, large sites do operate on it, and scalability doesn't ALWAYS come back to the programming language... your example of Facebook is a bit offside). Facebook has spent a good portion of the last years creating Hiphop at first, and then HHVM in order to scale PHP. But we really shouldn't be comparing to PHP. PHP would have been a fine decision for this site provided it be completed well.

[Bitcoin_BOy$]

Thank you everyone, for your replies.

@mprep well you've given a nice debate here, you almost changed how I see things here  .
Let's we all agree with the idea of a new software, back to the date of epoch talk building NodeJS wasn't highly recommanded, contradictory to the situation today,
in the view of Security and speed, it's highly rates those days, + Javascript is the programming language of the future web.

The purpose of this thread is to find a solution for our new forum software,
make a reasonable decision about what to do now:

Simple of questions:

Shall we continue with Epochtalk ? If No keep in mind that hundreds of thousands already spend.
Is there any urgent design upgrade or feature missing for current version ? (Maybe at the time we're waiting for the new software there's some urgent upgrades..)


Everyone kindly participate with questions and answers.

[JohnnyDoe2]

The answer to that question should be obvious:

EpochTalk:
Completely new system for people to get used to
Someone has to write a system to convert all the data from this forum to the new one
Someone has to write a system to redirect all the URLs that have been indexed in search engines to the new ones
Users will likely have to reset their passwords

Stick with SMF:
Everyone is used to this system
You can get new features and a modern design whenever the admins decide to upgrade (though that seems like it isn't going to happen now)
Proven stability and reliability backed by a strong community

Apparently the admins here would rather continue using outdated software instead though. Can't blame people for leaving when the admins don't care about the community.

[Vod]

Apparently the admins here would rather continue using outdated software instead though. Can't blame people for leaving when the admins don't care about the community.

New trolls take their place daily, no worries. 

[mprep]

Stick with SMF:
Everyone is used to this system
<...>

EpochTalk:
Completely new system for people to get used to
<...>
Users will likely have to reset their passwords

It's an online forum - the core concepts are still the same. Sure, people are going to need to adapt to changes in where certain function can be found, but I'd say the current forum software scares off more new people yearly than it would lose if old users had to adapt to a somewhat different forum software package.

EpochTalk:
<...>
Someone has to write a system to convert all the data from this forum to the new one
Someone has to write a system to redirect all the URLs that have been indexed in search engines to the new ones

That's part of the development specifications.

Stick with SMF:
<...>
You can get new features and a modern design whenever the admins decide to upgrade (though that seems like it isn't going to happen now)

And lose all the custom features already implemented into the old SMF 1.x (or, again, have to hire people to reimplement them). And introduce a plethora of security flaws not present in the already heavily patched SMF version that the forum uses.

I wouldn't call SMF 2.0's default theme modern either. It's better than what we currently have, but it's far from modern.

Stick with SMF:
<...>
Proven stability and reliability backed by a strong community

The forum's SMF software has already been hacked... twice: https://bitcointalk.org/index.php?topic=4405796.0

Causes for the aforementioned hacks:

• 0-day exploit in SMF
• Combination of an SMF exploit, password hashes from the first hack and a backdoor

While a small SMF forum might not need bulletproof security (hence why extensive and expensive audits aren't particularly common in open-source forum script development), Bitcointalk, the first and largest dedicated cryptocurrency forum, probably does.

[JohnnyDoe2]

Stick with SMF:
Everyone is used to this system
<...>

EpochTalk:
Completely new system for people to get used to
<...>
Users will likely have to reset their passwords

It's an online forum - the core concepts are still the same. Sure, people are going to need to adapt to changes in where certain function can be found, but I'd say the current forum software scares off more new people yearly than it would lose if old users had to adapt to a somewhat different forum software package.

EpochTalk:
<...>
Someone has to write a system to convert all the data from this forum to the new one
Someone has to write a system to redirect all the URLs that have been indexed in search engines to the new ones

That's part of the development specifications.

Stick with SMF:
<...>
You can get new features and a modern design whenever the admins decide to upgrade (though that seems like it isn't going to happen now)

And lose all the custom features already implemented into the old SMF 1.x (or, again, have to hire people to reimplement them). And introduce a plethora of security flaws not present in the already heavily patched SMF version that the forum uses.

I wouldn't call SMF 2.0's default theme modern either. It's better than what we currently have, but it's far from modern.

Stick with SMF:
<...>
Proven stability and reliability backed by a strong community

The forum's SMF software has already been hacked... twice: https://bitcointalk.org/index.php?topic=4405796.0

Causes for the aforementioned hacks:

• 0-day exploit in SMF
• Combination of an SMF exploit, password hashes from the first hack and a backdoor

While a small SMF forum might not need bulletproof security (hence why extensive and expensive audits aren't particularly common in open-source forum script development), Bitcointalk, the first and largest dedicated cryptocurrency forum, probably does.

And yet you're still two versions behind in SMF 1.1...

Plenty of other sites (both large and small) still use SMF without any issues. Nothing is guaranteed to be bulletproof.

[mprep]

Stick with SMF:
Everyone is used to this system
<...>

EpochTalk:
Completely new system for people to get used to
<...>
Users will likely have to reset their passwords

It's an online forum - the core concepts are still the same. Sure, people are going to need to adapt to changes in where certain function can be found, but I'd say the current forum software scares off more new people yearly than it would lose if old users had to adapt to a somewhat different forum software package.

EpochTalk:
<...>
Someone has to write a system to convert all the data from this forum to the new one
Someone has to write a system to redirect all the URLs that have been indexed in search engines to the new ones

That's part of the development specifications.

Stick with SMF:
<...>
You can get new features and a modern design whenever the admins decide to upgrade (though that seems like it isn't going to happen now)

And lose all the custom features already implemented into the old SMF 1.x (or, again, have to hire people to reimplement them). And introduce a plethora of security flaws not present in the already heavily patched SMF version that the forum uses.

I wouldn't call SMF 2.0's default theme modern either. It's better than what we currently have, but it's far from modern.

Stick with SMF:
<...>
Proven stability and reliability backed by a strong community

The forum's SMF software has already been hacked... twice: https://bitcointalk.org/index.php?topic=4405796.0

Causes for the aforementioned hacks:

• 0-day exploit in SMF
• Combination of an SMF exploit, password hashes from the first hack and a backdoor

While a small SMF forum might not need bulletproof security (hence why extensive and expensive audits aren't particularly common in open-source forum script development), Bitcointalk, the first and largest dedicated cryptocurrency forum, probably does.

And yet you're still two versions behind in SMF 1.1...

Plenty of other sites (both large and small) still use SMF without any issues. Nothing is guaranteed to be bulletproof.

And those 2 versions fix a total of 3 (rather basic) security flaws and none of the flaws that caused the forum to get hacked:

SMF 1.1.21                                            April 22 2015
===============================================================================

January 2015
-------------------------------------------------------------------------------
 ! XML post preview was broken in 1.1.20

SMF 1.1.20                                                       October 1 2014
===============================================================================

September 2014
--------------------------------------------------------------------------------
 ! XSS possibility if HTML used in maintenance mode title (Reported by guest)
 ! Various parts of the package system could allow XSS attacks (Reported by Arantor)
 ! Add session check to post preview to prevent XSS from html tag through forged forms (Reported by emanuele)

The fact that the last versions were still fixing XSS security flaws really says something about the amount of attention dedicated to security.

While plenty of sites use SMF, very few of them are such big targets. Alongside the fact that classical forums are dying (and thus it's getting harder to find bigger ones as time passes), very few of them cover topics with enough politics and financial interest to warrant continously attacking the forum.

[JohnnyDoe2]

All three of those XSS things are relatively minor and pretty much require admin access to exploit (only admins can enable/disable maintenance mode, only admins can manage packages and only admins can use the html tag). At that point you're pretty much screwed anyway.

If security is so important, wouldn't it be better to spend all that time and money helping a project that has helped you instead of reinventing forum software? Isn't that the whole point of Open Source?

[mprep]

All three of those XSS things are relatively minor and pretty much require admin access to exploit (only admins can enable/disable maintenance mode, only admins can manage packages and only admins can use the html tag). At that point you're pretty much screwed anyway.

Yet those are still XSS exploits that would've never even been present had the developers paid more attention to security when starting the project. XSS is one of 3 (the other being SQL injection and CSRF) most common (and thus often easiest to exploit) security exploits. Exploits that many web development frameworks include protections for by default (e.g. Django). If someone decides to build consumer-facing web software from scratch, one that should be able to withstand constant poking and prodding, making sure that these exploits are patched by default (either through libraries or writing their own abstractions for processing user input, fetching DB data and processing form data) should be their top priority. In the end, the core issue isn't the exploits themselves - it's the development process that let them slip past unnoticed.

With that said, I can't really blame the SMF devs that much - the software (at least according to the changelog's chronologically first entry) is around 15 years old. Couple that with the fact that it's a community-driven project and the resulting software is bound to have some holes in it. Future proofing non-enterprise software to withstand 15 years of intense scrutiny is a bit of tall order, especially for something started in the mid 00s. However, that still leaves Bitcointalk with the need for something more secure and fitting to handle it's use case.

If security is so important, wouldn't it be better to spend all that time and money helping a project that has helped you instead of reinventing forum software? Isn't that the whole point of Open Source?

Fair point. The reality of the situation is that it's much easier to write code than to read it. Improving and patching legacy systems is a massive pain compared to developing something from scratch, especially when you have a sufficient budget for it. Obviously, starting over has it's own issues (having to reimplement a plethora of functionality the old software already has), but if you are trying to develop something bulletproof and the old software's structure wasn't designed with security as the number 1 priority in mind, starting over might be your best option.

With all of this in mind, I can't really say whether starting over from scratch was the best option but there's definitely merit to the idea of avoiding existing projects and starting over. Then again, as you've mentioned, there's also merit to contributing all that development effort towards an existing open-source project. I guess we'll see if starting over was a good idea when (or if) this gets deployed to Bitcointalk.