Hacker Timesnew | past | comments | ask | show | jobs | submit | more JCB_K's commentslogin

Could use transition-delay. Supported in all browsers except IE.


THAT IS SO USEFUL.


from the article:

It's built into the normal iPhone texting application and turned on by default. When my Mom texts another Apple user, iMessage will automatically route her message over the Internet. She doesn't have to approve this, and honestly, probably won't even know the difference.


How does your phone know that another phone has iMessage? Is it set up manually by the user or do phones lookup the phone number on Apple's servers? If the latter then would it be possible to reverse engineer this to test if any number was an iOS device?


Your phone number is associated with your Apple ID. So I'm guessing they just reverse lookup the number you're texting to determine if iMessage can be used. It can definitely be reserved engineered. Just text any number from an iOS device and see if it switches to iMessage. The only caveat is users can remove their phone number association with iMessage so you could never be 100% sure.


I see.

Do you know if messages are encrypted from device-to-device on BBM or if they are just encrypted to the hub like I message seems to be


BBM messages are encrypted end-to-end. However, BBM messages sent through the BlackBerry Internet Services (BIS) network (i.e. via your carrier) are encrypted using a RIM possessed by RIM. That means, that if/when required, they can be subpoenaed and asked for those messages.

The same is not true for BBM messages sent via the BlackBerry Enterprise Server (BES). Those are also encrypted, but using a key possessed only by your company's IT department. That means that if someone wants to read you messages, they have to subpoena your company. RIM can't help them, at all.

I'm not sure what happens when a BlackBerry connected via BES sends a BBM to a person using BIS, or even another BES network. Either decryption and re-encryption occur, or it reverts back to using RIM's private key. But it would be safe to assume that BBM messages sent within your own company's BES network are safe and secure.


The problem with that approach is that he expects be extradited to the US as soon as he gets to Sweden. Oh and you might call it nitpicking, but he's not convicted of rape yet, let alone charged with it.


I still don't understand why Sweden is considered more likely to extradite to the US than Britain is...


In the UK an judge may make an independent determination that his 'crimes' are of a political nature and therefore not extraditable. In Sweden, there is a newish form of extradition, temporary surrender, where it is thought the decision can effectively be made by politicians instead of judges. Is he better off with a judge or a politician?

Sweden has recent form for taking legal shortcuts in this area.


I don't think many consider Sweden to be that. Maybe he is just trying to escape his accusations in Sweden?


No, they've offered several times to allow Swedish officials to conduct whatever formalities they need to in the UK. They've refused.

Sweden also has a history of dropping prisoners off at the airport where they get met by people who are DEFINITELY NOT CIA agents and disappeared.


No it doesn't really, it keeps your HTML clean. Sure, there's better ways of getting a MacBook into your webpage, but this definitely shows the power of the :before and :after selectors.


It may keep your HTML clean, but it makes your CSS messy!


That's why I said there's better ways of getting a MacBook into your webpage. But my point still stands, :before and :after are very powerful.


I'd much rather have clean, reusable HTML. CSS you can use preprocessors to abstract away the messiness.


Aren't you using templates and macros for HTML already?


Changing how the HTML macros expand likely ends up requiring CSS changes (in practice, though not necessarily in a theoretically-ideal code base). One change in two places, vs one change in one place.


No, I typically write entirely client side applications.


Any reading recommendations for someone who isn't?


> No it doesn't really, it keeps your HTML clean.

You can also keep your kitchen clean by stuffing all the dirty stuff into the cupboards.


Funny that all 3 companies you mention are money-related, which is a tough nut to crack in most countries. There's so many rules and regulations which all differ from country to country that I think it's quite understandable for companies like these to focus on 1 country first.

BTW, obviously all startups handle money in some way, but for these 3 it's a bit more complicated, as they're providing financial services to third-parties. (Ebay+Kickstarter to sellers/buyers, Stripe to sellers.)


The challenges that finance related startups face on a global market are complicated and costly but to me the underlying problem is how startups are organized in the first place.

You have a small team, often located in the valley or major US city, that expects to spend years working on developing their business model, product and infrastructure. Even if they are fabulously funded all efforts seem to be US centric because there's no way you can split so few people across so many countries when you're still developing the foundations of your business.

Instead of the typical startup organization that all but guarantees that you will expand too slowly to other markets, startups should look into more flexible forms of organization that allows them to set up partnering organizations in other markets. Imagine if your startup from day 0 has co-founders that are solely responsible for offshore markets development, pr and marketing. These co-founders would be an interface between your business and a specific country or region that actively engages with his market so that customers knows what is happening and what your startup's plans are for their market.

What you pay in equity and title you get back in a vibrant presence and a highly skilled and competent person that can guide you through each country's customs, laws and regulations, and bureaucracy.


You need to have found a viable business model, AND convince someone to partner with you, instead of cloning you - though it sounds reasonable that they would if you already have the infrastructure set up.

That said, it is an interesting idea, I know of at least one startup founder that's trying to do just that.


Finding a co-founder is indeed challenging and I can see how an offshore co-founder must seem like an insurmountable challenge but I believe it's possible. There are countless of bright and driven people who are hungry for a cause, more meaning in their life or just being part of something grand. You can find and recruit these people but you should primarily focus on great ideas and passion and not equity, money, etc. Also, tech entrepreneurs are so savvy and global these days that you can expect to find them on all kinds of communities such as HN and use filter them out based on documented past experiences (e.g. Github, Stack Overflow), recommendations (LinkedIn) or their online presence (blogs, twitter). Challenging but not impossible and destined to become easier as our community, business and recruting online tools improve.

Ultimately it is a question of persuasion, to rally up interest and support for your cause and we've been doing this as long as we've been walking upright.


the regulatory environment variations between countries is a great point

to address the point more generally, the IFC (private investment arm of the World Bank) does a report ranking the ease of doing business across countries: http://www.doingbusiness.org/rankings


That'd really sucks if you're relying on them as a business owner, but it's also a lesson to avoid relying on products still in development.

I'd be interested to know what this policy change is though. I believe Visa didn't work on iZettle in the UK since launch.


A worthy note to add to this is that the market for credit card payment in, at least Denmark, is almost monopolized through nordic payment provider NETS (http://nets.eu). Their prices are steep and iZettle was for many a much cheaper and easier alternative.


Yer, they don't really say what policy Visa changed, what it involves etc.

I have this feeling that they're trying to stop the likes of iZettle, because they're working on their own payment solution -- which I don't hope!


This is just goodwill-in-disguise. They've collected money on behalf of publishers, without consent, and now they realise that was a bad idea. They understand they obviously can't get away with keeping the money, but they don't want to invest the time into you know, actually contacting the domain owners.


"but they don't want to invest the time into you know, actually contacting the domain owners."

That is not a viable option to tar them with accusations of not taking. I am sure the vast bulk of domains have amounts of money set aside grossly less than the cost to either party to even start talking to each other. If you want to hand me $1.21, I don't even want to hear from you. (There's hardly any way to do that anyhow without losing most or all of it to fees.)

No, the only other possibly alternative is to return the unused money to those who gave it, but that may have its own problems.


"That is not a viable option to tar them with accusations of not taking."

Right, but this does suggest a good way for them to give a good faith effort. What if they put the effort into contacting all X content providers/publishers who 'earned' $Y or more? Even if it were somewhat costly, my appreciation would kick in if I knew they spent time to contact everyone who had earned $20 or more.

Even if the rest of the money went to charity, I'd still have a higher opinion of the way they've ended this operation.

Update: Their terms of services (7b, "Payments") states they won't pay out for amounts under $50. Sounds high given the expectable long tail, but they could put in work to contact those publishers.


Another option could be to allocate the money between the site owners that have registered in the same proportions as before. If they set a date to do this, and the planned amount for most sites ends up being significant, this may provide an incentive for more people to register.


They stole the idea from Superman III


They offered a service similar to adblock and noscript, but offered money back to the sites to make up for the loss of ad revenue. To my eyes, your post came across as critical of this service, so I apologize if I misunderstood, but you should be leveraging even harsher criticism against projects which deny sites their revenue and don't offer that money back to them.


offered money back to the sites

That's where the problem lies, they first took money from users, and then "offer" to pay it back. They should've done it the other way around, only charging money for sites which actually signed up to the service.

They've done a good job at making it sound like a great service for publishers, but when you think about it a bit more it's quite shady.


There's no charging for reading on sites that have signed up. It was a voluntary monthly payment for them to try to distribute evenly to publishers based on your use, not a "use Readability on x.com, pay Readability $1 which we'll transfer to x.com" model. If it were the latter, I'd agree with you, but it's nothing like that.


As Groxx said, the money was collected, but not on behalf of the sites. The only reason it was offered back to the sites was because of good will. They didn't have to pay them a dime. They could have easily pocketed the $5/mo.


Is the complaint that they are holding the money in the hopes that people will claim it? Or that they should have been giving it all out to the ones who did register, and every new source would start from zero?

"... they don't want to invest the time" in hunting down the owners of millions of domains? Yeah, that's clearly a good use of $115k - it'll only eat through that much in employee pay by the time they get through, oh, a couple percent. Only a couple percent of which will respond, only a couple percent of which will respond in a timely manner.

If they had given all the money they received to all the current registered publishers, would there be complaint? Instead, they're taking what seems to me to be a more moral stance, which is to hold it until they register, to more-accurately distribute the funds, instead of favoring the people who joined first.


It seems like this is made by the team formerly known as Sofa. Both the person who posted it and the name in the screenshot used to work there.


I really don't see the point of separate apps. The main Facebook app, Facebook Messenger, Facebook Photos...what's next?

Anyone who can enlighten me why this would be a good strategy? Seems like unnecessary fragmentation to me.


It's the iOS paradigm to make feature simple standalone apps. Why do you think Apple has both a "Photo Album" and "Camera" app? And both a "Phone" and "Contacts" app?

Many users upload photos to Facebook, so there's a huge incentive to make an app that makes it simple to do this. Even if the main Facebook app has feature parity with FBPhotos, it's still going to come with all of the cruft.


This.

Two things people do that FB wants channeled through their systems: Photos & Chat.

Replacing your camera app with FBs means that all photos go to Facebook, which also represents the most important content on Facebook.

If your photos and your friends photos are all on FB then they go to FB.

If everyone you know is on FB then you'll probably use FB to talk to them. Thus, the chat ecosystem. Because FB is device and OS agnostic, it works even better than what Apple is trying to do with iMessage.

So why separate apps? Because people today already do these things as separate apps. You take a photo with your camera and then upload to FB. Now you just take a photo. This is actually what Google does with G+ and its automatic photo uploads. But FB can't do that, because they don't own the device ecosystem so this is their technique...for now.


Friends uploading all of their photos to Facebook,

Pros: -Pictures of their girlfriends naked

Cons: -A complete lack of relevance and editorial purview.

Every photo a user uploads to Facebook sends a message about who that person is. Out of about 300 photos I take on my iPhone, 1 makes it to Facebook. I have a few friends that upload lots of crap. For the most part, those friends had their feeds blocked by me fairly quick. These are not interchangeable events.

Facebook's biggest threat is a loss of meaning through noise, not users using an alternative app to capture their media.

As for Facebook Messenger, I'll be damned if I let Facebook permanently record every last one of my private message for eternity.


"Facebook's biggest threat is a loss of meaning through noise, not users using an alternative app to capture their media."

This is true of any data aggregator and visualizer. I'd argue they, probably next to Twitter, are the best at attempting to handle it within a social context.

I guess my thought about photos is incomplete in that making FB a storage for media means that your mean average of shared media will go up as well (it's already there, might as well). We see this in bulk uploads.

I agree that there is a certain amount of selectivity involved - but we vary as individuals. I think only in the last couple of years, after the fad of being able to toss everything online in heaps - have we begun to understood how our online perception is made.

"As for Facebook Messenger, I'll be damned if I let Facebook permanently record every last one of my private message for eternity."

Agreed. That's why I'm off it.


Plus it's pretty seamless replacement. Same label "Camera". Same icon, just with a blue background instead of grey.


TBH, I'm kind of surprised Apple is totally cool with this since one of the AppStore guidelines is to not create apps that replicate core iOS features. Now I know that Facebook's Camera app does more than take photos, but they are a direct replacement for the Camera and Photos apps that are native to iOS. Making the name and icon so very similar is close enough to be construed as an obvious intent to confuse/mislead.


I noticed that when changing the location settings in "Settings". The default Camera app was listed immediately next to Facebook Camera, confused me for a moment.

I wonder if Apple will make them add "Facebook" to the app name to avoid confusion, since it's the exact same name currently.


Smart move. Didn't realize it at first :)


It's somewhat in following with the Unix paradigm; do one thing, do it well.


Not always. Regarding core Unix commands yes (like 'ls', 'cat') but look for example at 'git' which is a real beast.


Not to veer too far from the main discussion, but 'git' isn't just some giant monolithic binary. The 'git' command is a wrapper around a bunch of different, relatively modular binaries. They each even have their own man page. (e.g. 'git push' maps to 'git-push'). Each is just a unique action that can be applied to a common data structure (the git repository).


I know. And still all these different libs are accessible by one UI/route ('git').


Do an ls /usr/libexec/git-core/ (or your operating system's equivalent) some time. The fact that the porcelain exists does not mean that the plumbing does not.


Look closer at git, and you'll see that it's actually a collection of smaller programs (each of the git commands is made as a separate executable before being combined into git)


git is just a facade for the git-* commands.


So when can we do $ camera | fb-photo | facebook | sed 4 | awk ?

Chaining the utilities is the crux of the Unix paradigm, remove that and you're left with individual utilities that are far less powerful than when chained together.


It's somewhat possible though not very widely used.

Basically, any iOS app can register a URL scheme and be opened with that scheme and anything after that by another app. This is used for example by Camera+: http://api.camerapl.us/app-api

With their API, another app can launch Camera+ to edit a photo and Camera+ sends the user back to the original app with the data of the edited photo.

Facebook uses it for single-sign-on of third-party app. (i.e. user taps "sign in with Facebook", the Facebook app is launched, the user taps "Accepts" and is redirected towards the original app)

One big limitation of this mechanism is that it's very much ad-hoc.

Another existing mechanism is the one where apps can register themselves as being able to handle a certain type of documents. You can then open a document from another app.


Now. With android intents (ok, not cool as pipes, but the idea is there)


You can do it on iOS as well. You can go from the facebook camera app to the main fb app. (Any app can do this, but the point of the article is fb so i used them as the example)


Is the link between the two apps hardcoded on iOS?

On Android you can have any camera app | any photo editing/filters app | any social network upload where each app is chosen by the user which seems closer to the idea of pipes to me.


This is a great example; it almost works like UNIX pipes except that each application has to take an explicit action to share its result with the next application in the pipeline. But like UNIX apps that do something anti-social like rewrite the input file (hello, GNU Recode), that can be worked around.

For those of you that don't use Android, the process works like this. You take a picture. The camera app provides a "share" button. You click "share". Then you're presented with a list of all applications that handle photos. So you can share to G+, or email a photo, or run it through filters, or whatever. The camera application never needs to know about the filter application (the reverse is also true). This makes it very easy to reuse code and for users to design their own workflows. Platforms don't really like this, since they don't have total control over the user experience, but for us users, it's pretty darn nice.

(You can also register URL handlers, so that something like clicking a link to Google Maps in your email automatically opens up the Google Maps app to the same state. Again, pretty useful.)


Yeah it's something that Facebook would hardcode. Click on this person and instead of doing something here it sends you to that person's profile on their other app.

It isn't like intents on Android, but from the perspective of Facebook it is probably preferable. They don't want you to go to your choice of photo or social network or chat app, they want you to go to their app.


Which is why I said "somewhat". However, you can upload a picture from one app and interact with it in another, so that's... something I guess.


in fb camera, if you see someone is tagged, and you tap their name, it switches to the main fb app and shows their profile there. The notion of doing one thing well seems to be preserved.


"Why do you think Apple has both a "Photo Album" and "Camera" app? And both a "Phone" and "Contacts" app?"

I'd say that in any case, they had to have Contacts and Photo Album apps for the iPod Touch and iPad.

Why also include them on the iPhone? Well, Photo Album has more features than the Camera app (access to Events, Faces…) so it might be simpler to have one codebase for a Photo Album app shared with iPod Touch and iPad, rather than trying to put all the features of Photo Album in the Camera app. For me, it's better too because it makes the Camera app more easily replaceable. (as seen with the OP)

For the Contacts app, I'm not entirely sure since it seems to be a clear subset of the Phone app.


but what's weird is that the Facebook app also does both of these things already, just not quite as well. It's especially weird with Messenger because I think both apps can get push notifications.


We call the unix paradigm now the iOS paradigm?


The Unix paradigm is more about even smaller composable tools.


If I were Facebook, I would be thrilled at the idea. I'd want as many apps as Facebook has features, as long as we could get users to install them.

Right now "Facebook" is one app on iPhones and Androids, next to native apps like Camera and Photos. Imagine if Facebook was 10 or 15 apps, and they were the same across iOS and Android. For the Facebook-loving crowd, at least, they'd take up your entire home screen, and make the OS virtually irrelevant. For these people, it's more like anti-fragmentation (unification), on Facebook's platform.

I see this as similar to Netscape (built for a dozen platforms), or Office (for Mac): they're saying "don't worry about the OS -- we'll take care of that for you -- you only need to know that if Our Product is on top, then you know how to use it".


Because Facebook wants to be the platform and not the app. At some point we'll realize that Zuckerburg was out to replace Windows not Myspace


Agree with this statement. To compete with Microsoft, Apple, Google you need a platform (OS and phone). While Facebook messenger didn't really off, photos may be more of a popular transition as many send photos to Facebook anyway.


My experience with their app is that it's just so slow that being able to jump directly to Messenger when I need to use it saves me some time. I'm not sure if it's a good or a bad thing.


Making a separate app is not a solution. Speeding up your main app is.


Not easy to do on iOS when your main app relies on hooks to a web browser. iOS forces apps to use an older Javascript engine.


The same reason that one goes to "Camera" on an iPhone to take photos and goes to "Messages" on an iPhone to send messages. They do different things and it's clear when you open the app what you want to do. And though you can take photos from within Messages and can SMS photos from within Camera, it keeps things simple to have a clear intention for each app.


Anyone who can enlighten me why this would be a good strategy? Seems like unnecessary fragmentation to me.

Because they optimise a particular use case, which makes it more likely people will do something, which will make it more likely that facebook can use the shared content to drive more people towards facebook.

Take photo sharing. Photos are often spontaneous. So the more responsive, quick and simple it is to take a photo and share it the more likely it is to happen. Ideally I want to hit the photo app and by the time I've moved the camera up to my face be ready to take a photo. Facebook's new app is much closer to that experience than their current generic app. I bet that it will get more photos on Facebook. More photos == more traffic == more dollars.

You can't fix the current generic Facebook app to work as a better photo taking app - since if you made it the ideal photo taking application, it would be sub-optimal at the other things that facebook want the mobile app to do.


For photos specifically, it takes me an average of 10 minutes to upload a photo on their iPhone app if I'm on my cell connection. The 10 minutes consists of a combination of upload attempts, fails, freezes, etc. It's just a horrible experience.

If this new standalone photo app will let me easily, quickly, flawlessly upload photos to Facebook, then hell yeah.


This doesn't make any sense to me. Why not just fix the main app?


The main app is optimized for reading your timeline. Fetches notifications, friends, messages etc.

It is hard to optimize for different tasks at once, while I'd also argue it would be possible to strike a good balance. But I think it is a pragmatic decision rather than try to achieve that perfect balance, and let several instagrams take over, do the right thing for each task and a year down the line knowing usage patterns, with much better hardware, you can think about a consolidated app.


I completely agree. Facebook's iPhone app experience is overall horrible in my experience. It just simply rarely works.

I think they should fix it. But if their current solution is to make the photo taking/sharing a separate app, that's fine with me. I use Facebook mobile more to take/share photos than anything else on Facebook.


They started off with that approach, the app had a pseudo home screen with quick access to different functions.

Ultimately I think it boils down to what you think of when you want to do take a photo or send a message which maps to (Facebook Camera, Facebook Messenger) more naturally than just Facebook.


When you try to design a mobile app you quickly realize how little real-estate you have on a phone to build a complex interface. Facebook is a ridiculously complex app when you think about all of the things you can do.

Facebook might be working under the assumption that they can make cleaner, simpler products by breaking them out into smaller functional units all backed by the same social graph.

Or this could be a relic of something the Sofa team was working on before the Instagram deal.


> Or this could be a relic of something the Sofa team was working on before the Instagram deal.

Probably. And the Instagram deal is still under review from the FTC for quite some time, so it'll be awhile before we see any major integrations, I think.


When taking photos, Facebook wants it to be the first thing users think of. By stripping other separate features, users won't be that easily confused about the purpose of the app. I'd venture and say few users immediately go to the current Facebook to upload a photo, but if there is a separate app, then the other features won't distract them from what they want to achieve. Basically: "Want to share a moment? Think Facebook. NOT twitter. NOT instagram."

That's my guess.


I like it. There's less wading through non-native in-app menus. I want to read my timeline or generally waste time? Facebook. I want to send a quick message to someone I don't text? Facebook Messenger. I want to share a new photo or three from my friend's commencement? Facebook Photos.

One tap and I'm there, and ready to do what I want to do. Maybe two, if I have the app in a folder.


Icon space. Assuming most people don't put their related apps in folders, they instead have it all on display. Like shelf space at the grocery store. The more product users can see with your brand, the more they'll

1) Trust the brand

2) Use it

I'm sure if they haven't integrated them yet, they will; and that in itself is a kind of lock-in you could only otherwise get if you owned the OS.


I agree, at this point, my iPhone needs a new folder created specifically created for Facebook produced apps. I already have too many camera apps installed, many of which upload to Facebook.

I understand Facebook trying to keep users in their ecosystem, but separate apps for each part of their service seems a bit much to me as well and I don't see how it's a good long term strategy if they continue this cycle. We'll know they don't really have a strategy if they release an app solely for rejecting requests to play Words with Friends and Draw Something with others.


Can the point of separate apps be justified in reinforcing that Facebook is more of a platform than just a website?

They also have Pages & Messenger. I like the idea of isolating these aspects because it gives more utility to these individual functions rather than obscuring them by combining all of the site's functionality into one, slow and poor performing app.

Overall, the app looks good but I'm not sure what's the deal with Instagram now.


I had the Facebook app for Android before they split it into 3. The version just before the split was unstable for uploading photos. It was consistently crashing whenever I tried to upload a photo.

I'm not sure what was the source of the crash, but I can see how breaking up the Facebook application into smaller pieces would make it easier for devs to maintain well.


I think it makes sense to have two apps for FB. One's for content creation, and optimized for that. The other's for when you're bored and killing time scanning through the stream. When I'm sitting somewhere and I see something I want to share, it makes sense to just use the app that's optimized for posting a photo


Facebook always had photo sharing features built into their apps, but was still dominated by Instagram. Lesson here is that mobile apps are very task oriented - people have apps to check their email, get directions, etc. Having function specific apps for Facebook makes sense here.


They want to own the mobile ecosystem. After they release enough Facebook _____ apps, they can (a) lean on the OS makers to give them preferential treatment, ala Twitter in iOS, and/or (b) release a Facebook phone with "all the apps you already know and love".


I actually asked myself this question several times until I recently found an answer.

They want to compete with what's app and bbm. Facebook messenger is the SMS application of people who have internet on their phone. It's actually brilliant when you think about it!


I think this might have something to do with the App Center they are launching soon. Making people install their own apps through the app center will make them more familiar with it.


Because it ropes in people like me who don't want the native Facebook app on their phone, but want to keep in touch with friends who use Facebook messages.


Less click. Instead of Facebook -> Camera -> whatever you directly access the feature you want.


A guess: Facebook phone with separate facebook apps all built on android.


That was my first thought as well until I saw that the app was only iOS first....doesn't mean it wont happen, but I'm still not ready to bet on it.


Next is Facebook Ads.


In part, for the same reason (in part) that Instagram blew up. iOS doesn't have Android's intent feature.


Billion dollars for cloning one instance of a feature of android. So much for the "apps sell, not features" theory


When Cloudflare has a high-profile client, they'll often blog about it. It's a smart marketing technique, because they lift on the publicity around the client.


True, but the most important thing is that it worked.

This scenario is actually daunting for most small sites: it's four days out, you're about to get tons of traffic, and keep it to yourself :)

Setting up Google-load-capable infrastructure in 4 days is trivial for some you on hackernews, but non-trivial for others.

Cloudflare sounds like a convenient, drop-in solution for when you don't know how to configuring your own reverse-proxy.


Cloudflare is much, much more than a reverse-proxy. It is more comparable to Contendo (now part of Akamai), but Contendo charged thousands for what CloudFlare does for free.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: