tashmahalic

Thanks for the feedback. Will fix.

What about "modern wiki" is interesting to you?

Your constructive suggestions about Grok are very welcome.

There is definitely useful parenting knowledge that's not intuitive to many parents.

I'm building a site to collaboratively document topics like this. I just created a "Good Parenting" topic in case you and others in this thread would like to pool their knowledge into something concise and useful.

https://grok.how/24/Good-Parenting?source=hn

Home Owners Association

I like that you have an opinion about what should be different and are doing something about it (creating your own language).

What's the reason you want deterministic object lifetimes? So that you get predictable performance? Can reason about performance?

What payment methods do you like?

How else is the startup scene broken in Boston?

It works like ssh. When you send or receive securely, you can see a fingerprint of your peer's public key, and a fingerprint of your own public key. Your peer sees these too.

To mitigate MITM attacks, ask your peer for their public key fingerprint using something other than WireOver: phone, SMS, email, PGP email - whatever you're comfortable with. That's your "second factor of authentication".

Your approval is cached so you only need to do it once.

We'll better explain this on the website.

There's a PGP key on the contact page: wireover.com/contact

Yes.

We're changing it.

Thank you, commenters. Your feedback carries weight.

We have a "Friends of WireOver" group that we'll occasionally ask for feedback, advice, and new release testing. Email friends_at_wireover_dot_com to join.

It's a salted hash. That page is corrected, thanks.

They fixed it.

Open to suggestions on how to improve the language (http://wireover.com/contact)

There's a tradeoff between collision resistance and fingerprint string length. We chose MD5 because people are comfortable with it in ssh, it's a shorter string to verify than something like SHA-256, and because we planned to make your peer's entire public key base64 available if you really wanted to go that extra mile (currently not available).

What would you prefer personally: (1) MD5 fingerprint for convenience AND entire peer public key base64 available if you really want; vs (2) just a longer SHA-256 fingerprint.

I suspect that you tried it when we were in private beta. The UI and reliability are significantly improved. Give it another try.

The sender needs a Pro account for the transfer to be secure. If a Pro account sends to a non-Pro account, the transfer will still be secure. More answers at http://wireover.com/faq.

It’s significantly more convenient.

Indeed, but they are no more. There’s still a relatively unmet need for sending huge files fast (and free) and for sending with incredibly strong security.

There's a "more" link at the bottom of each page. It stops working after the page sits for a few minutes.

If this is fixed, I will sigh one less time each day.

how will you generate revenue?

(and if there's no one here with an informed answer, where should i ask this question? Thanks.)

We need to decide if Go is a suitable language to build our app with. Our app will be deployed on end-user 32-bit systems, and needs to work 100% of the time.

Is there someone here who can say either: (1) Go will fail sometimes on 32-bit systems, don't use it until this problem has been fixed, or (2) there are things you can do to always avoid the 32-bit problems.

?

This is my understanding of the problem: when a Go program is initialized on 32-bit windows or linux systems, it tries to allocate 512MB of contiguous virtual ram. When the virtual address space is too fragmented, the initialization will fail and the Go program won't start. Is this correct?

We're considering using Go for an end-user desktop application for Mac, Windows, and Linux. Of course, we don't have control over whether our users have a 32-bit or 64-bit system. And, of course, our app has to work 100% of the time. What can we do to make Go work 100% of the time on these 32-bit systems?

My understanding is that if the public key is transmitted from the receiver to the sender through our server instead of directly, that should be secure to MITM. This assumes that peer connections to our server are secure (SSL).

Does this meet with your understanding?

We're logging exceptions and connectivity issues to help us troubleshoot problems.

We are NOT logging anything I think you'd be concerned about (this is our BE NOT ANNOYING principle at work).

When we get our Privacy Policy and Terms of Service up, it will be something to the tune of: you own your data, we don't; we don't share your personal information (unless the law requires); and, we don't store your files once they're delivered (bytes go P2P anyway most of the time, so our servers usually don't even see them anyway).

If you have a Pro (secure) account, your bytes will be encrypted in a way that even we can't decrypt. That's the kind of security we would want as users.

I'm use linux too, I feel your pain... I'm sorry we don't have it for you yet. We will.

You can now install WireOver at home with your personal email, and install it at work with your work email.

Why would you like them to be linked somehow?

Good suggestion, thanks. We have some polishing of the UI to do.