discuss Why .app when we have app stores?

[FavourB]

Hi everyone,

This question is mainly thrown to the veterans and those who have long time history with domains, i believe from there experience they can render some explanation, not like the owe we the newbie any, but out of curiosity i just wish to know why the .app extension was created.

1&half years into the industry and it still makes no sense to me

So please why .app when we have various app stores?

 

[branding]

app was designed to replace .com as the number 1 extension on the web, but it fell short and the registry was seriously considering removing the .app extension all together.

Never happened.

APP is unlikely to take off it is more likely in the near future that apps will replace domains.

It has already taken off.

 

[FavourB]

.app was designed to replace .com as the number 1 extension on the web, but it fell short and the registry was seriously considering removing the .app extension all together. All we can do is hope .ecom will come out soon to replace .com as this is the e-commerce age and .com makes less sense then .ecom. .APP is unlikely to take off it is more likely in the near future that apps will replace domains.

.ecom? that's gonna end up being a failed project and a joke extension just like some extension, I think .info falls into that category, over 50 .info domains in my earlier days, I didn't even get an offer by mistake

 

[branding]

I think .mobi has more value than .app, like i can understand .mobi can represent the mobile version of a software, like flashscore.mobi and all of that, but .app hell no

Google is gonna loose there second attempt, lets watch out for the 3rd.

You can't compare .mobi to .app. different eras, different endgame for the registry. I'm not particularly fond of .app but you can't deny the successful launch of the TLD. Sales are there.

Google is doing quite well actually. They pick their open TLDs with usage in mind. Although not all as successful (.page) there are some with decent adoptation amongst endusers, like .dev.

 

[FavourB]

You can't compare .mobi to .app. different eras, different endgame for the registry. I'm not particularly fond of .app but you can't deny the successful launch of the TLD. Sales are there.

Google is doing quite well actually. They pick their open TLDs with usage in mind. Although not all as successful (.page) there are some with decent adoptation amongst endusers, like .dev.

To be Frank it was in the course of this thread I got to know about .dev

Seems Google is not tired of creating boring extensions

 

[branding]

To be Frank it was in the course of this thread I got to know about .dev

Seems Google is not tired of creating boring extensions

Beauty is in the eye of the beholder. I'm actually quite fond of .dev .

As boring as some of their TLDs may seem, for Google (unlike most other registries) all their extensions are part of a bigger picture. Some will succeed, some will fail, but ultimately it will give them more power, flexibility and data to control the direction the internet is heading.

 

[FavourB]

Beauty is in the eye of the beholder. I'm actually quite fond of .dev .

As boring as some of their TLDs may seem, for Google (unlike most other registries) all their extensions are part of a bigger picture. Some will succeed, some will fail, but ultimately it will give them more power, flexibility and data to control the direction the internet is heading.

yeah sure beauty lies in the eyes of the beholder.

What's your success rate with .dev?

Probably I can see something there to buy and hold off for.

.Dev is built for programmers and coders right?

 

[MadAboutDomains]

Those that have been here for a while saw the hype over .mobi when it was launched. The thing is that it was a very different time, back when the extensions were limited to ccTlds and the original GTLDS and mobile websites resided on the 'm' subdomain and were static monstrosities without character. Every extension that was launched was a huge deal because of the limited number of them.

Back then 'app' wasn't common parlance and 'app stores' didn't exist like they do now and we didn't have the problems that apps cause today, like having to develop the app multiple times and the need to support many platforms. The front end web languages were also just developing or didn't support all of the nice stuff that they do today.

Front end Web development is an entirely different beast, too, it has received a LOT of love since then. We now have HTML5 and CSS3 supported widely and browsers support more things than ever (access to biometrics, camera etc). We have TypeScript for more robust JavaScript with type checking and compilation, we have kit like babel that allows you to write modern modular Javascript and will transpile it down to support old browsers and pollyfills the gaps automatically.

We're at a point now where the gaps between native and Web experiences are being filled in and Google and others are reimaginging how mobile Web experiences can have an app feel about them... and it looks like they're just getting started. The worlds of web and native apps are literally merging together and that's a good thing for innovation.

As for mobi/app now, .mobi registration volumes are half that of .app (300k vs 700k) which isn't exactly a ringing endorsement of either extension. The .app extension is the 11th most registered gTLD according to ntldstats.com. When I look at .mobi now it seems strange because its not a common phrase unlike 'app'. I don't think I've seen a modern use of mobi in recent years and even the registry website has been left to rot.

 

[NickB]

Is it me or will Dapp's eventually make App's obsolete?

 

[FavourB]

Is it me or will Dapp's eventually make App's obsolete?

Yeah that's the question just like @MadAboutDomains said about .mobi being obsolete same will apply to .app,

so far app stores still exist and I don't think Google have any plans to stop and focus on building there app store on the .app the created, it wont make sense to app creators, iPhone also has there's up and running, Samsung currently has there's

So this brought me to decide that the .app extension is of no use in this century

Same Google created it, same destroyed it

Google can make use of Google.app and set a trend for others to follow, maybe by then there would be value on .app

I got concerned after I saw a .app sale yesterday on DAN platform, and I was like does this still exist, I went to namebio to look up past sales and it wasn't encouraging.

 

[branding]

yeah sure beauty lies in the eyes of the beholder.

What's your success rate with .dev?

Probably I can see something there to buy and hold off for.

.Dev is built for programmers and coders right?

Oh, I wouldn't advice anyone to invest in them. Not a lot of action being reported.

I got a dozen of them when it launched and have 2 or 3 left I think. Made some sales but nothing noteworthy. Nothing that cannot be accomplished with .com but I liked the keywords so couldn't let the opportunity pass

 

[FavourB]

Oh, I wouldn't advice anyone to invest in them. Not a lot of action being reported.

I got a dozen of them when it launched and have 2 or 3 left I think. Made some sales but nothing noteworthy. Nothing that cannot be accomplished with .com but I liked the keywords so couldn't let the opportunity pass

Interesting, your investment actually paid off, but I guess you wont be picking them now again right.

 

[branding]

Interesting, your investment actually paid off, but I guess you wont be picking them now again right.

Unless it's for personal use, probably not. But you know, if the right name comes along for the right price I just might.

 

[MadAboutDomains]

The thing with the word 'app' is that it is a common word that normal people use to refer to something, unlike dapp which is only known by a minority of geeks referring to the manifestation of the use of underlying blockchain technology.

Given that the average person doesn't generally call apps something different based on their underlying technology (sql vs nosql for example), I don't see why dapp apps would be any different cause the average person doesn't know about such things, they just tap away at the screen regardless of what technology it uses under the hood.

If blockchain tech becomes a mainstay of app development, it'll still be an app to the average person imho

Though there is no stand out reason to host your site on a .app other than if the developer decides that they want to do so, it's not a case of which phrase is most popular at a given time or whether one phrase will beat another or make it obsolete.

 

[Nametree]

I'm happy you see the opportunity many of us don't do, so what would you advice to look out for before picking this extension, there are many great names left to be picked up, how do you siphone the valuable ones?

There are many good names that have been dropped in recent months, some of the early players who bought them by the dozen in early access probably couldn't afford the renewals.

Like with anything else except for .com, the only potentially worthwhile investment is in singular, common, one-word English names. Unfortunately, most that are still available hold $100-1000 yearly renewal price tags. So the economics don't make sense for domainers. The ones that don't have premiums... well, they've been picked over.

I don't have any advice and I wouldn't suggest anyone invest in .app unless you're wiling to hold for a few years. I personally have a few dozen I picked up at release that I'm still holding, and I've picked up some great ones this summer on the drop. I've sold enough to afford to reinvest in some names with higher renewals. So I'm biased, and it might not work out in the long run, but I think we're in a very different time than when mobi was launched and .app has the recognition and the usage no other new TLD has had.

 

[Mr. Deleted]

Google failed with .mobi startup in the past...
So this is their 2nd attempt...

 

[FavourB]

Just 1 example

 

[Paul]

So please why .app when we have various app stores?

Keep in mind that apps don't exist in a black box; most communicate with web services behind-the-scenes. For security and other technical reasons, it often makes sense to perform this communication on a separate domain name. Historically, there were various ways of going about this; for example, the app for example[.]com might communicate with exampleapp[.]com or example[.]io. app[.]example[.]com would've also been acceptable in many cases, but using a subdomain lacks some of the security benefits of using a separate SLD.

Now, the app for example[.]com might opt to use example[.]app. This has the added benefit of forcing HTTPS in modern clients, as app is in the HSTS preload list--a huge boon for security.

I wouldn't expect most .app domains to be visible to consumers, regardless of how Google markets them; at least for now, they're probably going to be used for convenience purposes within services, rather than as domains intended to be typed into a web browser.

 

[mdrn]

Progressive Web Apps (PWAs) are replacing native apps, and .app is the only extension that best matches PWAs.

This and web apps in general, not only for mobile but desktop as well.

Many SaaS services could use .app and have it work well with their branding.

Wish I was able to register some names when .app first came out. One thing I don't like is that a lot of good names are premium and you have to pay the premium price yearly. Other than that caveat for increasing usage, I think .app will grow in the tech world during the next couple of years.

As always, time will tell.

 

[Steven McEvoy]

Why have any ngtld?

 

[mdrn]

Keep in mind that apps don't exist in a black box; most communicate with web services behind-the-scenes. For security and other technical reasons, it often makes sense to perform this communication on a separate domain name. Historically, there were various ways of going about this; for example, the app for example[.]com might communicate with exampleapp[.]com or example[.]io. app[.]example[.]com would've also been acceptable in many cases, but using a subdomain lacks some of the security benefits of using a separate SLD.

Now, the app for example[.]com might opt to use example[.]app. This has the added benefit of forcing HTTPS in modern clients, as app is in the HSTS preload list--a huge boon for security.

I wouldn't expect most .app domains to be visible to consumers, regardless of how Google markets them; at least for now, they're probably going to be used for convenience purposes within services, rather than as domains intended to be typed into a web browser.

Great points about the security benefits Paul.

Having a separate SLD, especially with the forced HTTPS, is a nice secure setup. I can definitely see companies adopting that framework.

 

[Masay]

. dev and .app is the best alternative for developer to handreg their desire names. most of them don't want to pay premium for .com domains.

Seems Google is not tired of creating boring extensions

for end user .dev .app is a good news.

 

[MadAboutDomains]

Keep in mind that apps don't exist in a black box; most communicate with web services behind-the-scenes. For security and other technical reasons, it often makes sense to perform this communication on a separate domain name. Historically, there were various ways of going about this; for example, the app for example[.]com might communicate with exampleapp[.]com or example[.]io. app[.]example[.]com would've also been acceptable in many cases, but using a subdomain lacks some of the security benefits of using a separate SLD.

Now, the app for example[.]com might opt to use example[.]app. This has the added benefit of forcing HTTPS in modern clients, as app is in the HSTS preload list--a huge boon for security.

I wouldn't expect most .app domains to be visible to consumers, regardless of how Google markets them; at least for now, they're probably going to be used for convenience purposes within services, rather than as domains intended to be typed into a web browser.

Great points about the security benefits Paul.

Having a separate SLD, especially with the forced HTTPS, is a nice secure setup. I can definitely see companies adopting that framework.

Unfortunately I think that there's been a misunderstanding about HSTS and communication over HTTPS...

It's not any use for enforcing security of back end systems, HSTS is a browser instruction. So there's no difference between .app and any other domain in this regard.

https://tools.ietf.org/html/rfc6797#section-2.3.2.2

One should restrict communication to their backend systems to HTTPS by other mechanisms.

As for subdomains not having the same security. What like?

 

[mdrn]

Unfortunately I think that there's been a misunderstanding about HSTS and communication over HTTPS...

It's not any use for enforcing security of back end systems, HSTS is a browser instruction. So there's no difference between .app and any other domain in this regard.

https://tools.ietf.org/html/rfc6797#section-2.3.2.2

One should restrict communication to their backend systems to HTTPS by other mechanisms.

As for subdomains not having the same security. What like?

No misunderstanding.

It is simply convenient for security out of the box. Automatically on HSTS preload list, so not possible of making http connection. If not on HSTS preload list, you run the risk of loading a redirect page of http to https which can be intercepted. Also with HSTS, you can prevent SSL Stripping Attacks (MitM).

You can add domains on this preload list if they meet the requirements, so every domain is capable of this - but you need to set it up.

From my experience, having a separate SLD is to simply sandbox your domain from your other domains. You can set up different rules for this domain. Can also mitigate risk during a DNS attack or hijacking depending on how/where your domains are stored. Doesn't need to be .app but again, since .app is on HSTS preload list, it makes for an easy and secure solution.

Any domain can achieve these benefits, as they should, but .app is conveniently secure out of the box. Not revolutionary but it sure is a positive benefit.

Using the word 'secure' loosely, please don't read into it more than necessary. Secure in HTTPS sense, nothing more.

 

[MadAboutDomains]

Automatically on HSTS preload list, so not possible of making http connection.

Using the word 'secure' loosely, please don't read into it more than necessary. Secure in HTTPS sense, nothing more.

It's not secure in a HTTPS sense when you can connect over HTTP.

It wouldn't automatically protect an app or communication on the backend, only when connecting through a browser that supports HSTS.

So as long as people know that it's all good.

As explained by this quick bit of command line:

 

[mdrn]

It's not secure in a HTTPS sense when you can connect over HTTP.

It wouldn't automatically protect an app or communication on the backend, only when connecting through a browser that supports HSTS.

So as long as people know that it's all good.

As explained by this quick bit of command line:

Show attachment 166693

Correct and I understand what you are saying, but backend you would ideally have it connect through HTTPS of course.

Thank you for the explanation.