Live data from Hacker News

Revolt: Open-source alternative to Discord

revolt.chat

401–410 of 413 posts

Re: Revolt: Open-source alternative to Discord

#401
post #378

Earlier quoted context omitted.

Define 'supports.' It's still against the TOS -- my point is only that we don't specifically look for third party client users and we have no specific plans to do so.

Just curious -- where in the TOS are third party clients forbidden? I've read it a few times, and I'm not seeing it.

Probably:

> You agree not to (and not to attempt to) (i) use the Service for any use or purpose other than as expressly permitted by these Terms;(ii) copy, adapt, modify, prepare derivative works based upon, distribute, license, sell, transfer, publicly display, publicly perform, transmit, stream, broadcast, attempt to discover any source code, reverse engineer, decompile, disassemble, or otherwise exploit the Service or any portion of the Service, except as expressly permitted in these Terms;

It's a catch-all but the best restriction that prevents third-party clients is probably 'prepare derivative works based on' and 'reverse engineer' (which you would need if you want your third party client to use any regular client API calls, or if you want to support signing in with the user-facing login page/qr login).

Re: Revolt: Open-source alternative to Discord

#402
post #245
post #112

Earlier quoted context omitted.

These days Java applications are supposed to embed the JVM using jlink images or even native installer (see jpackage). So you shouldn't even know if the app is written in Java when you run it.

The problem with jpackage/jlink is that most teams are stuck on an antiquated runtime and those tools didn’t ship until Java 14 (correct me if I’m wrong about the version). My own company is still making new projects on Java 8.

At work, we use some pretty complex stuff in our builds, including linking to C libs, Groovy testing, Kotlin modules, as well as the majority of the code in Java. It took quite a lot of effort, but we managed to move to Java 11 this year.

It's great to be able to use new Java language/platform features. We're moving to Java 17 next year once the dust settles (it will be the first LTS release in 3 years and comes up this month - Sep 2021)... it will be a much easier migration as there's nothing like the big Java 9 barrier to cross.

I can't understand why anyone would start something new in Java 8, all traditional Java tooling already works really well with Java 11 and even Java 17.

Re: Revolt: Open-source alternative to Discord

#403

Earlier quoted context omitted.

I dunno, maybe it's easier for them than to implement quite a large existing spec, or they just wanted to.

> easier (...) to implement quite a large existing spec They don't have to implement all of the spec themselves. Nothing stopping them to leverage the existing base libraries and SDKs to build the functionality for the client. > or they just wanted to. Well, ok, but when I see such a strong manifestation of NIH syndrome it really reflects poorly on the project.

I disagree, the use of MongoDB reflects poorly on the future of the project. In my opinion, a custom protocol does not. They intend for the app to be an alternative to a giant like Discord, so the protocol being custom leaves them with the freedom to introduce features Matrix didn't consider.

In opposition of NIH syndrome, using others work often locks you into the framework of their thinking, which can often be flawed. So to make improvements within the framework, you must think outside of it. Matrix might not be flawed, but it is purpose built for a specific task, a task that likely won't capture all possible use cases of this project. Perhaps it would be the right move to use in the beginning, but once the project matures it may become a limitation.

Re: Revolt: Open-source alternative to Discord

#404
post #378

Earlier quoted context omitted.

Just curious -- where in the TOS are third party clients forbidden? I've read it a few times, and I'm not seeing it.

Probably: > You agree not to (and not to attempt to) (i) use the Service for any use or purpose other than as expressly permitted by these Terms;(ii) copy, adapt, modify, prepare derivative works based upon, distribute, license, sell, transfer, publicly display, publicly perform, transmit, stream, broadcast, attempt to discover any source code, reverse engineer, decompile, disassemble, or otherwise exploit the Servic…

A third party client like Ripcord isn't a derivative work.

It also wasn't made by reverse engineering any of Discord's code. Even if it were, these rules still wouldn't apply to using third party clients.

Re: Revolt: Open-source alternative to Discord

#405
post #402
post #245

Earlier quoted context omitted.

The problem with jpackage/jlink is that most teams are stuck on an antiquated runtime and those tools didn’t ship until Java 14 (correct me if I’m wrong about the version). My own company is still making new projects on Java 8.

At work, we use some pretty complex stuff in our builds, including linking to C libs, Groovy testing, Kotlin modules, as well as the majority of the code in Java. It took quite a lot of effort, but we managed to move to Java 11 this year. It's great to be able to use new Java language/platform features. We're moving to Java 17 next year once the dust settles (it will be the first LTS release in 3 years and comes up t…

> I can't understand why anyone would start something new in Java 8,

Quite frankly: they just don't know better and they just don't care. I could go on for pages, but in short the people running the show are just really inexperienced and are pretending not to be. I'm going to start applying for jobs soon as its beginning to feel hopeless.

Re: Revolt: Open-source alternative to Discord

#407

Earlier quoted context omitted.

> easier (...) to implement quite a large existing spec They don't have to implement all of the spec themselves. Nothing stopping them to leverage the existing base libraries and SDKs to build the functionality for the client. > or they just wanted to. Well, ok, but when I see such a strong manifestation of NIH syndrome it really reflects poorly on the project.

I disagree, the use of MongoDB reflects poorly on the future of the project. In my opinion, a custom protocol does not. They intend for the app to be an alternative to a giant like Discord, so the protocol being custom leaves them with the freedom to introduce features Matrix didn't consider. In opposition of NIH syndrome, using others work often locks you into the framework of their thinking, which can often be flaw…

the specific task that matrix was built for is super generic: syncing encrypted blobs of json in realtime across a decentralised network. you can build pretty much any comms system on top of that; the question is more whether you want to write your own thing from top to bottom or build on an existing protocol. If you want decentralisation or e2ee for free, then Matrix is a nice way to get it. It doesn’t stop you layering other features on top - you just have to know what you’re building on.

Re: Revolt: Open-source alternative to Discord

#408

Earlier quoted context omitted.

That's a confusing statement -- JS/Node and Golang are comparable (memory safe) languages for API server backends.

Golang is only memory safe if you're not using the concurrency features. It doesn't protect against data races which can break safety.

Rust hasn't magically solved concurrency safety either, as linearity is not enough.

GC'd languages (Java, Go, Haskell etc) are safer than Rust by default, you just have the tradeoff of GC. Note that this isn't always a tradeoff as GCs can outperform static allocation in scenarios like large dynamic heaps.

Haskell is the safest for concurrency because of the strictly typed functional semantics.

Re: Revolt: Open-source alternative to Discord

#409

Earlier quoted context omitted.

I'd wager that in general the crowd frequenting this site are much more interested in what the back-end / protocol is written in than what the web app is.

I guess I'm not a part of this "general" then. Solutions should solve a problem. Tech demos should demonstrate tech.

You might not be, hence 'general' and not 'all'...

This application solves a problem. An application is more than its front end...

Re: Revolt: Open-source alternative to Discord

#410

Earlier quoted context omitted.

Great choice, thanks for being practical and realistic. Hate on HN does not predict any kind of product metric.

Electron is almost never a great choice for anything. It saddens me to see people on a website for nerds defend it.

What is "a great choice"?
Post reply on HN