chrisballinger

The main reason they don't allow WebM is because only H.264/H.265 are hardware accelerated on iOS devices.

How does the money enter the network in the first place? You can use services like Venmo without linking payment information, but obviously you can't withdraw your balance.

Except you need to use macOS to develop iOS apps.

Perhaps it's confused by the many images and videos of tigers swimming in water?

Not for malware running in user space.

We built something similar to this for our Kickflip.io HLS/S3 live video streaming service. The original version is closed source but we rewrote a generic open source Python library called storage_provisioner [1] for a client. It's minimal and super simple.

We also made a Django-Rest-Framework module that wraps storage_provisioner called django_broadcast [2]. Working with AWS/S3 can be a pain, hopefully these tools can help.

1. https://github.com/PerchLive/storage_provisioner

2. https://github.com/PerchLive/django-broadcast

From what I understand bitcode is still somewhat architecture dependent and wouldn't work well for ARM<=>x86 translation.

> Firebird has been upgraded to version 3.0.0. It is unable to read back Firebird 2.5 data, so embedded firebird odb files created in LibreOffice version up to 5.2 cannot be opened with LibreOffice 5.3. Since a future version of firebird will have a backwards compatibility module, some future version of LibreOffice (embedding this future version of firebird) will also be able to open these older files.

> ODB files created by LibreOffice < 5.3 can be manually converted to LibreOffice 5.3 format by using Firebird 2.5 to convert the data to archive format, and replacing the database data within the ODB by the archive format version. To do this, install a stand-alone Firebird 2.5, and use its "gbak" tool to convert the file "database.fdb" to "database.fbk" within the odb file. Don't forget to remove the .fdb file.

I don't use this feature so I don't know how popular it is, but it seems like this could cause a lot of problems for people. They probably shouldn't have updated to Firebird 3.0.0 until they had an automated migration process in place, instead of instructing end users to manually convert their old files from the command line.

Thanks for testing so thoroughly. Some of these problems are likely related to server incompatibilities, but others are definitely client bugs like the QR code stuff. Please report individual issues here [1]. Thank you!

1. https://github.com/chatsecure/chatsecure-ios/issues

Most public servers are pretty bad in terms of modern XMPP features [1]. Trust is also a big issue, but one of our goals is to solve this problem by making it much easier to run your own server. We currently default to Dukgo for new registrations but they don't support many of the XEPs required for a good mobile experience (0198, 0313, 0357).

1. https://gultsch.de/compliance.html

MAM will be in 4.1, but there's currently no timeline for that release yet. We plan to do a 4.0.1 release soon to resolve some bugs, and then start working on 4.1. If you signed up for the 4.0 beta, you'll get notifications for the next beta as soon as its ready.

That's correct. Our main differentiator from Signal/WhatsApp/Wire/Telegram/etc is that we have no centralized messaging infrastructure. Users are free to run their own servers, or connect to any 3rd party providers they trust. We also have integrated Tor support, but plan to remove that once iCepa reaches maturity.

Thanks! It's been quite the rollercoaster. We're extremely grateful that Moxie resolved the App Store / GPL license issue with their Signal Protocol libraries.

This is exactly what the meek [1] pluggable transport does. It was developed by David Fifield, of the original authors of the domain fronting paper [2].

1. https://trac.torproject.org/projects/tor/wiki/doc/meek

2. https://www.bamsoftware.com/papers/fronting/

One caveat I noticed is that you need to use 'cu' instead of 'telnet' or 'screen' or the console gets garbled during wifi setup, at least on my machine. Took a while to figure that one out.

What about uintptr_t?

Another Core Data alternative to try is YapDatabase: https://github.com/yapstudios/YapDatabase

It is similar to Realm in a lot of ways, with a simple concurrency model, and native objects (key/value/collection). It's built on top of SQLite so you can use extensions like secondary indexes, full text search, RTree. You can also use SQLCipher for full database encryption, and there's another extension to do automatic syncing via CloudKit.

Caveats are it only runs on Apple platforms, doesn't have cross platform sync, and isn't backed by VC funding. If you need those things then Realm is definitely your best choice.

I expected angular.io to be a flashy example Angular 2 SPA and was disappointed when I realized it was just a regular old static HTML website. I guess most of the content is more suited for a static site. At least the search bar on the docs page looks like it has some Angular going on. Also it would be neat if the docs had dynamic examples instead of screenshots.

Thank you Moxie!

Although we personally trusted and would've moved forward with Moxie's informal permission to distribute SignalProtocol within ChatSecure on the App Store, our funder required us to get the legal details squared away or we'd lose our funding. This announcement is an amazing gift for us, and for other GPL compatible Mac/iOS apps.

This announcement also more broadly benefits the copyleft community. There has been a decline in GPL apps on Apple platforms, particularly because of this conflict between the GPL and Apple's App Stores. It makes it clumsy to accept pull requests because you need a CLA to allow relicensing for distribution. There's a also lot of FUD from anti-Apple copyleft zealots. Having a good template for other developers who wish to stick to strong copyleft without worrying about App Store issues is a great contribution to the Apple-friendly copyleft community.

I've been pretty quiet about this, but over the last couple of months I have been trying to negotiate with Moxie a way to distribute the GPL licensed AxolotlKit on the iOS App Store in ChatSecure (which is open source). After being denied a license, I was told by Moxie that I would be unable to write a non-GPL AxolotlV3 implementation because there is not publicly available documentation, and that any re-implementation will necessarily be a derivative work because the source code must be consulted. You may notice the AxolotlV2 documentation has been removed... and there was never documentation for AxolotlV3. The only public spec is the original double ratchet, and a few blog posts, which don't include things like signed prekeys and 4-way DH.

I've heard that the L-Theanine [1] in green tea is responsible for a calmer caffeine effect. Although I haven't tried it, I've heard that you can get the same results by taking a supplement before your morning coffee.

1. https://en.m.wikipedia.org/wiki/Theanine

Do you love the mission of Open Whisper Systems but can't commute to SF, or don't want to commit to a full time position? Hit me up!

Moxie - Let me know if you'd like me to remove this comment, I definitely don't want to poach your applicants! I'll always send cool people your way, especially when they seem like a good fit for your team.

ChatSecure | Berkeley, CA | East Bay or SF Preferred, Remote Negotiable | Contract Only (Interns OK)

Want to get paid to write free and open source privacy & security software?

ChatSecure is a free and open source encrypted messenger for iOS and Android that supports XMPP, OTR, Tor, SQLCipher, TLS certificate pinning, and more. We are NOT funded by VC, and instead have been grant funded since 2012 by the following awesome organizations: The Guardian Project, OpenITP, Rights Action Lab, and the Open Technology Fund. For more information see https://chatsecure.org

In the upcoming months we will be hiring mobile, frontend, and backend developers with some or all of the following qualifications:

* iOS: Objective-C, Swift, C, AutoLayout, Storyboards, CocoaPods, iPad, Cocoa, Mac UI, XCTest, an app in the App Store

* Android: Android 4.0 SDK and higher, Android NDK, Java, C, Android Studio, Gradle, JUnit, an app in the Play Store

* Frontend: HTML5, CSS, JavaScript, Bootstrap, Jekyll, Angular, React, Ember, your own website

* Backend: Python, Django, Ubuntu, Go, Rust, Docker, your own API

* General Programming: data structures, flow control, POSIX, standard stuff. Experience with Test Driven Development would be nice.

* Security: Some basic knowledge of cryptography is a must, but don't stress about the advanced stuff. You must have experience with modern secure / defensive coding practices, familiar with common vulnerabilites in native code, identifying potential areas of concern, surface area analysis, etc.

* Open Source contributions are highly recommended: individual projects, larger projects, pull requests, bug reports, QA, documentation, modular coding practices, semantic versioning, Travis-CI, GitHub, git. Know how to find the best existing open source libraries that solve a need. Be able to quickly assess a library's code quality and general maintenance health compared to similar projects. Know when to just rewrite it from scratch instead. Know how to properly publish your new open source library.

* Freelance Contrators Only: Sorry, there are currently no full time or permanent positions. If you're looking for that steady 9-5 you really should be looking somewhere else, because this ain't it. Fortunately Obamacare has made buying individual health insurance a lot better for us freelancers.

* Equal Opportunity: We do not discriminate based on race, color, sex, religion, national origin, age, disability, sexual orientation, genetic information, reprisal, socioeconomic class, radical political beliefs, tattoos, hair color, clothing style, or otherwise.

* Berkeley, CA: East Bay or SF preferred. Remote may be negotiable though!

For people who might be a good match for this position, but would prefer full time employment (and can commute to San Francisco), check out moxie's Open Whisper Systems hiring post elsewhere in this thread. They are also hiring iOS, Android, and mobile UI designers.

If this seems like your jam.. awesome! Hit me up at chris@chatsecure.org with a subject like "ChatSecure iOS Job from HN", a link to your GitHub profile, and a short introduction. No recruiters.

We put a lot of work into it this year.. really hope people find it useful!

Soon I'll be resuming work on a privacy-conscious push server design, originally intended to enhance the poor user experience of the existing ChatSecure iOS client (OTR/XMPP/Tor).

The general idea is that you'd fetch tokens from the server that allow people to send pushes to you, then distribute them to trusted contacts over an secure channel. Contacts would then be able to send you pushes from any endpoint of choice. Somewhat less metadata than existing solutions, and an opportunity for client diversity.

Oh hey, I wrote that! There are plenty of apps that are distributing LGPL code on the App Store, for example, VLC for iOS [1] includes FFmpeg. The static linking requirement on iOS 7 and earlier prompted some proprietary app developers (like Sparrow [2]) to distribute their object files to allow re-linking.

Now that iOS 8 offers dynamic frameworks, I'm not sure if this situation has changed. Even though they are dynamically linked, it is impossible for the end user to replace a library due to the code signing requirements.

1. http://www.videolan.org/vlc/download-ios.html 2. https://web.archive.org/web/20131013023029/http://sprw.me/lg...

It will soon! After playing around with their latest Signal 2.0 beta that integrates TextSecure support, I honestly would recommend using Signal unless you specifically need Tor/OTR or want to host your own XMPP infrastructure.

I'd love to make this happen, but it won't be possible unless they support open federation, which is currently impossible when using your phone number as the identifier. I do plan to support Axolotl in conjunction with our provider-agnostic push solution, which could potentially provide a bridge between the two platforms.

I was excited about the possibility of federated XMPP over mobile hidden services, mainly because of the built-in NAT traversal. It could make creating a "good enough" XMPP server as simple as buying a cheap Android phone, installing an app, and keeping it plugged in somewhere.

Most people don't choose their devices like a developer would and instead focus on things like ease of use (or the best marketing campaign). Just because a platform doesn't offer completely perfect theoretical security and privacy, users should still have access to tools that can help.