Live data from Hacker News

Command Line Interface for Signal

github.com

61–70 of 75 posts

Re: Command Line Interface for Signal

#61
post #33

> at least Java Runtime Environment (JRE) 11 Yeah I stopped right there. I've had enough of one app wanting IBM Java, another wanting Oracle Java, another wanting Sun Java, another wanting 32-bit Java, another wanting 64-bit Java, another wanting Java 8, another wanting Java 11, ... I really wish this were written in literally any other language, ideally one whose compiler can be apt-gotten on a default Ubuntu instal…

  apt install openjdk-11-jdk

Re: Command Line Interface for Signal

#62
post #56
post #44

So... we're gonna write code in python ...that interfaces with a CLI ...that's a wrapper around a Java library ...that communicates with Signal's API? Would it not be better to write code in python that communicates directly with Signal's API?

> Would it not be better to write code in python that communicates directly with Signal's API? Only the official builds of the official signal clients are allowed to connect to the signal servers, everything else is considered unauthorized use (under the CFAA) by moxie, Signal’s lead dev. At least that’s what he said on the bugtracker of the fork "LibreSignal" while forcing them to shut their fork down.

[deleted]

Re: Command Line Interface for Signal

#63
post #55
post #21

Earlier quoted context omitted.

I still use Keybase heavily for work and personal contacts, and the Linux client just got updated. It's not really a platform with high visibility usage (which is a benefit IMHO).

There are several great e2ee features: - 250GB of free storage - personal subdomain that serves your public folder - git (e2ee)

>250GB of free storage

Would be more useful if you could upload more than one file at a time.

Re: Command Line Interface for Signal

#64
post #43

Earlier quoted context omitted.

Fascinating. I know how to write an app that requires java 8 (just use lambdas) or 11 (just use newish TLS), but wow does one even write an app that needs 32-bit or 64-bit java? Or that works with Sun java but not with others?

JNI libraries.

Good point.

Re: Command Line Interface for Signal

#65

This makes me really miss Keybase.io. Anyone around from Keybase? Will it just bit rot away or will it get some attention/love in the future?

I really thought Keybase was going to be huge. It had such potential!

I wish it had created a SSO feature to auth 3rd party apps. I think that would have boosted adoption.

I think it's going to rot away, but I really wish it wouldn't.

I really liked the storage and sharing features, the ability to create groups which have git, storage, chat etc that just works. But the devs should have integrated with or made a layer on top of github, gitlab and other git hosting services because a lot of folks wouldn't move their codebase.

I wonder if we'll ever see something similar? "Digital Identity Management" seems like it would be a great use case. What with a wallet feature built in, it seems like there's not much of a leap to having multiple currencies represented there. Plus it could have implemented a password repository or integrated Bitwarden into the storage backend and have the whole thing signed/encrypted by GnuPG.

Re: Command Line Interface for Signal

#66
post #63
post #55

Earlier quoted context omitted.

There are several great e2ee features: - 250GB of free storage - personal subdomain that serves your public folder - git (e2ee)

>250GB of free storage Would be more useful if you could upload more than one file at a time.

I guess it's intended for use on a computer. I could drag multiple folders/files into my /keybase/private folder.

Re: Command Line Interface for Signal

#67
post #33

> at least Java Runtime Environment (JRE) 11 Yeah I stopped right there. I've had enough of one app wanting IBM Java, another wanting Oracle Java, another wanting Sun Java, another wanting 32-bit Java, another wanting 64-bit Java, another wanting Java 8, another wanting Java 11, ... I really wish this were written in literally any other language, ideally one whose compiler can be apt-gotten on a default Ubuntu instal…

You might want to have a look at presage - an implementation in rust: https://github.com/whisperfish/presage

Re: Command Line Interface for Signal

#68
post #59

This makes me really miss Keybase.io. Anyone around from Keybase? Will it just bit rot away or will it get some attention/love in the future?

What's so special about keybase? I feel like Signal is current solution to go to if you just need easy e2ee (espexially because of its big userbase). Otherwise it's Matrix for me as it offers "the future of messaging" (well, you wish)

Keybase does way more than just the messaging. Fundamentally it's a really cool solution to the digital identity problem. With that solved, they built a lot of useful tools around those identities, ranging from secure messaging to secure file storage and git hosting.

Re: Command Line Interface for Signal

#69
post #39
post #36

Earlier quoted context omitted.

Yes, the one that I linked, and then this one: https://github.com/LibreSignal/LibreSignal/issues/37#issueco... A Google Play app was taken down: https://play.google.com/store/apps/details?id=org.privatecha... A GitHub repo was removed: https://github.com/WizDom13/SignalPlus-Android After reviewing the thread, I think that it may just be that we have had a genuine misunderstanding over the meaning of the word enforcem…

It looks to me like those clients were removed due to trademark infringement (having "Signal" in their name), I don't think they were taken down because their code connects to OWS' servers (would GitHub or Google ever honour a takedown request like that?).

Sending messages to authors of third party clients that you are not ok with their use of your servers (literally the exact comment the link I and other posters shared):

> I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.

> If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

Yes, they mention both trademarks _and_ servers, and yes, if there was not a trademark issue, github and google would not remove the repo just for connecting to Signal's servers against Moxie's wishes.

However, the act of informing third party client developers that they are not allowed use the official servers is itself an act of enforcement - maybe one with not much teeth behind it unless he follows up with a legal complaint, but still nonetheless enforcement.

Re: Command Line Interface for Signal

#70
post #56
post #44

So... we're gonna write code in python ...that interfaces with a CLI ...that's a wrapper around a Java library ...that communicates with Signal's API? Would it not be better to write code in python that communicates directly with Signal's API?

> Would it not be better to write code in python that communicates directly with Signal's API? Only the official builds of the official signal clients are allowed to connect to the signal servers, everything else is considered unauthorized use (under the CFAA) by moxie, Signal’s lead dev. At least that’s what he said on the bugtracker of the fork "LibreSignal" while forcing them to shut their fork down.

Forcing?
Post reply on HN