Jump to content

SUBMITTED (25005) - [FEATURE] Nano canister size


The HERB5

Recommended Posts

We already have this in our database. Implementation must wait for the upcoming GPX schema release.

 

Any chance for an update on the status of this?

 

The GPX schema release seems to have died a lonely death since Moun10bike did make the comment that the API was now the delivery vehicle of choice. But there are more far reaching problems than just a change on Groundspeak. Use any third party software? Will this change be supported? What about paperless units, will the change be supported? I cobbled up a .gpx file with a nano container size. At least the unit did not brick but did show the container size as micro. My unit is a current production etrex 30, so if it is still in production, maybe, just maybe Garmin will do a firmware roll to support this container size. But maybe not. What about units out of production? not a chance. What about other manufacturer's, will they roll their firmware to support the new size? Or even worse, will their units brick? Changes like this can have lots of unintended consequences.

Link to comment

So does that mean the idea of a new "nano" container size is dead?

 

Also, don't forget when GPX 1.0.1 was introduced, not all units supported it. Luckily, there was the option of 1.0.1 or 1.0.0, whichever the user wanted to download.

 

If it hasn't been done in the last 10 years or so it probably is in the morgue, and if it is not in the morgue then it is in a persistent vegetative state.

 

And yes the 1.0.0/1.0.1 thing was because changes to the .gpx file caused some units to brick. It certainly is a possibility with additions to container size.

Link to comment

Changing the schema is a huge deal as they learned when they added attributes in the later release. They had to resurrect the old one. Garmins couldn't load them. Not sure if the newer ones can but the problem was solved by Clyde and I get attributes in my display on a Garmin. It is clear that API is the future and I wouldn't expect or even want to see them work on what is slowly becoming a legacy implementation.

Link to comment

should we not start by adding "nano" to the size block on the internet page ?

 

This is the base from where the other tools get their info.

 

I just had a look at the GPX schema and it looks to me like Groundspeak:container (the element for the cache size) is defined as a string and is not restricted. Currently that element can have several values and those currently in use are: Micro, Small, Regular, Large, Not Chosen, and Other. Putting "Nano" as a value for that element does not change the schema. Other than adding a couple of lines of code to validation code (assuming it exists) to allow "Nano" as a value, 1 line of code to add "Nano" to the select list, and some documentation changes, and changing the size block, implementing "Nano" as a valid container size looks quite easy and wouldn't require a change to the GPX schema or database either.

Link to comment

should we not start by adding "nano" to the size block on the internet page ?

 

This is the base from where the other tools get their info.

 

I just had a look at the GPX schema and it looks to me like Groundspeak:container (the element for the cache size) is defined as a string and is not restricted. Currently that element can have several values and those currently in use are: Micro, Small, Regular, Large, Not Chosen, and Other. Putting "Nano" as a value for that element does not change the schema. Other than adding a couple of lines of code to validation code (assuming it exists) to allow "Nano" as a value, 1 line of code to add "Nano" to the select list, and some documentation changes, and changing the size block, implementing "Nano" as a valid container size looks quite easy and wouldn't require a change to the GPX schema or database either.

 

It's just hard to know what things like paperless GPS units would make of a value they weren't expecting.

Link to comment

I just had a look at the GPX schema and it looks to me like Groundspeak:container (the element for the cache size) is defined as a string and is not restricted. Currently that element can have several values and those currently in use are: Micro, Small, Regular, Large, Not Chosen, and Other. Putting "Nano" as a value for that element does not change the schema. Other than adding a couple of lines of code to validation code (assuming it exists) to allow "Nano" as a value, 1 line of code to add "Nano" to the select list, and some documentation changes, and changing the size block, implementing "Nano" as a valid container size looks quite easy and wouldn't require a change to the GPX schema or database either.

It's not the nature of the data field that is the issue. The problem is that there are a lot of coders out there for whom the word "robust" is lost. When parsing the XML, they don't properly plan to deal with unexpected values. That goes for writers for PC apps, phone apps, and embedded firmware coders for handhelds. Edited by ecanderson
Link to comment

should we not start by adding "nano" to the size block on the internet page ?

 

This is the base from where the other tools get their info.

 

I just had a look at the GPX schema and it looks to me like Groundspeak:container (the element for the cache size) is defined as a string and is not restricted. Currently that element can have several values and those currently in use are: Micro, Small, Regular, Large, Not Chosen, and Other. Putting "Nano" as a value for that element does not change the schema. Other than adding a couple of lines of code to validation code (assuming it exists) to allow "Nano" as a value, 1 line of code to add "Nano" to the select list, and some documentation changes, and changing the size block, implementing "Nano" as a valid container size looks quite easy and wouldn't require a change to the GPX schema or database either.

 

It's just hard to know what things like paperless GPS units would make of a value they weren't expecting.

 

Since there isn't a constraint specified for the element, the value can be anything. The schema only specifies that it's a string. A GPS device should not expect it to contain one of values currently in use.

 

I would be pretty easy to tell what a paperless GPS unit would do. It would be easily testable. Edit a GPX file, change whatever is in the Groundspeak:container element to "Nano" and send it to the unit. It's a test that can be done now, without making any changes to the site..

Link to comment

should we not start by adding "nano" to the size block on the internet page ?

 

This is the base from where the other tools get their info.

 

I just had a look at the GPX schema and it looks to me like Groundspeak:container (the element for the cache size) is defined as a string and is not restricted. Currently that element can have several values and those currently in use are: Micro, Small, Regular, Large, Not Chosen, and Other. Putting "Nano" as a value for that element does not change the schema. Other than adding a couple of lines of code to validation code (assuming it exists) to allow "Nano" as a value, 1 line of code to add "Nano" to the select list, and some documentation changes, and changing the size block, implementing "Nano" as a valid container size looks quite easy and wouldn't require a change to the GPX schema or database either.

 

It's just hard to know what things like paperless GPS units would make of a value they weren't expecting.

 

Since there isn't a constraint specified for the element, the value can be anything. The schema only specifies that it's a string. A GPS device should not expect it to contain one of values currently in use.

 

I would be pretty easy to tell what a paperless GPS unit would do. It would be easily testable. Edit a GPX file, change whatever is in the Groundspeak:container element to "Nano" and send it to the unit. It's a test that can be done now, without making any changes to the site..

I have and my Etrex 30 shows it as micro and the square for micro is filled in. At least it fails in a some what acceptable manner. Since Groundspeak has ignored this request for the past 10 years I see no need for them to implement it at this late date.

Link to comment
Since there isn't a constraint specified for the element, the value can be anything. The schema only specifies that it's a string. A GPS device should not expect it to contain one of values currently in use.
In theory, theory and practice are the same.

 

In practice, they aren't.

Link to comment

This is the definition of a micro

 

Micro - Less than 100ml. Examples: a 35 mm film canister or a tiny storage box typically containing only a logbook or a logsheet. A nano cache is a common sub-type of a micro cache that is less than 10ml and can only hold a small logsheet.

 

No need to add anything since a nano is less than 100ml it is already defined.

Link to comment

should we not start by adding "nano" to the size block on the internet page ?

 

This is the base from where the other tools get their info.

 

I just had a look at the GPX schema and it looks to me like Groundspeak:container (the element for the cache size) is defined as a string and is not restricted. Currently that element can have several values and those currently in use are: Micro, Small, Regular, Large, Not Chosen, and Other. Putting "Nano" as a value for that element does not change the schema. Other than adding a couple of lines of code to validation code (assuming it exists) to allow "Nano" as a value, 1 line of code to add "Nano" to the select list, and some documentation changes, and changing the size block, implementing "Nano" as a valid container size looks quite easy and wouldn't require a change to the GPX schema or database either.

 

It's just hard to know what things like paperless GPS units would make of a value they weren't expecting.

 

Since there isn't a constraint specified for the element, the value can be anything. The schema only specifies that it's a string. A GPS device should not expect it to contain one of values currently in use.

 

I would be pretty easy to tell what a paperless GPS unit would do. It would be easily testable. Edit a GPX file, change whatever is in the Groundspeak:container element to "Nano" and send it to the unit. It's a test that can be done now, without making any changes to the site..

 

It's defined as a string although everything about Groundspeak's own site uses it as if it were a fixed option list (i.e. micro/small/regular/large/other/not chosen). So even though the formal specification allows any value to be used Groundspeak themselves have created a de facto standard that it takes one of 6 values. It's not entirely surprising that hardware vendors implement the same kind of interface that the largest geocaching site does, even if it is technically not the best way to go about development.

 

Anyone could tell what their GPS unit would do, but from a centralised perspective it would be a shame to introduce a new value only to find things start breaking all over the place. Even if the fault is technically with the hardware supplier it's inevitable that people would blame Groundspeak for changing something that caused things to fail.

Link to comment

This is the definition of a micro

 

Micro - Less than 100ml. Examples: a 35 mm film canister or a tiny storage box typically containing only a logbook or a logsheet. A nano cache is a common sub-type of a micro cache that is less than 10ml and can only hold a small logsheet.

 

No need to add anything since a nano is less than 100ml it is already defined.

 

It's not necessary but it would be useful to be able to filter them out.

 

If I'm in the mood to look for film pots and keysafes I'll consider anything called a "micro". With few exceptions I have little to no interest in finding nanos, so if I saw a cache listed as "nano" I'd know to ignore it unless there was something about it that made it worthwhile.

 

Personally I sometimes go out of my way to solve and find puzzle nanos but a traditional nano isn't something I generally have any interest in hunting.

Link to comment

should we not start by adding "nano" to the size block on the internet page ?

 

This is the base from where the other tools get their info.

 

I just had a look at the GPX schema and it looks to me like Groundspeak:container (the element for the cache size) is defined as a string and is not restricted. Currently that element can have several values and those currently in use are: Micro, Small, Regular, Large, Not Chosen, and Other. Putting "Nano" as a value for that element does not change the schema. Other than adding a couple of lines of code to validation code (assuming it exists) to allow "Nano" as a value, 1 line of code to add "Nano" to the select list, and some documentation changes, and changing the size block, implementing "Nano" as a valid container size looks quite easy and wouldn't require a change to the GPX schema or database either.

 

It's just hard to know what things like paperless GPS units would make of a value they weren't expecting.

 

Since there isn't a constraint specified for the element, the value can be anything. The schema only specifies that it's a string. A GPS device should not expect it to contain one of values currently in use.

 

I would be pretty easy to tell what a paperless GPS unit would do. It would be easily testable. Edit a GPX file, change whatever is in the Groundspeak:container element to "Nano" and send it to the unit. It's a test that can be done now, without making any changes to the site..

 

It's defined as a string although everything about Groundspeak's own site uses it as if it were a fixed option list (i.e. micro/small/regular/large/other/not chosen). So even though the formal specification allows any value to be used Groundspeak themselves have created a de facto standard that it takes one of 6 values. It's not entirely surprising that hardware vendors implement the same kind of interface that the largest geocaching site does, even if it is technically not the best way to go about development.

 

Anyone could tell what their GPS unit would do, but from a centralised perspective it would be a shame to introduce a new value only to find things start breaking all over the place. Even if the fault is technically with the hardware supplier it's inevitable that people would blame Groundspeak for changing something that caused things to fail.

 

That all makes sense. I mostly wanted to try to dispel the rumor that a Nano size has not yet been implement because it would require a change tGo the GPX schema. The addition would *not* require a change to the GPX schema. The argument that some GPS devices might break is a different argument and is based on the *speculation* that some GPS vendors have chosen an implementation which is not compliant with the GPX schema. GPS users could *help* here by trying a GPX file which has Nano specified as the value for Groundspeak:container element.

 

I know that there have been issues when GS *did* update the GPX schema which caused some GPS units to brick, but at this point all we really have is speculation that things would start "breaking all over the place" if the value for the Groundspeak:container element was "Nano" rather than one of the de facto standard strings. Jholly reported that it doesn't break a Garmin Etrex 30. I can test it on an Oregon 450 tonight. Anyone else want to chip in?

 

 

Link to comment

]In theory, theory and practice are the same.

 

In practice, they aren't.

 

My new favourite quote.

 

This is the definition of a micro

 

Micro - Less than 100ml. Examples: a 35 mm film canister or a tiny storage box typically containing only a logbook or a logsheet. A nano cache is a common sub-type of a micro cache that is less than 10ml and can only hold a small logsheet.

No need to add anything since a nano is less than 100ml it is already defined.

 

The idea would be to make the "common sub-type" into it's very own size. It's been done before with cache types, so it wouldn't be out of the question to be done here

Link to comment

<snip>

The idea would be to make the "common sub-type" into it's very own size. It's been done before with cache types, so it wouldn't be out of the question to be done here

Perhaps not out of the question but certainly highly unlikely given the request has been floating around for 10 years now.

Link to comment

]In theory, theory and practice are the same.

 

In practice, they aren't.

 

My new favourite quote.

 

This is the definition of a micro

 

Micro - Less than 100ml. Examples: a 35 mm film canister or a tiny storage box typically containing only a logbook or a logsheet. A nano cache is a common sub-type of a micro cache that is less than 10ml and can only hold a small logsheet.

No need to add anything since a nano is less than 100ml it is already defined.

 

The idea would be to make the "common sub-type" into it's very own size. It's been done before with cache types, so it wouldn't be out of the question to be done here

 

I understand it's your new favorite quote, but be advised that quote has been around since about 6 years before you started Geocaching. :laughing:

 

Yes, the "company line" is that nano's are micros, and should be listed as such. It doesn't work. I'd say most of the ones I see surfing the latest caches listings in my State (which happens to be the same as yours :) ) and adjoining states as well as Ontario are listed as "other". In other words, the majority of the Geocaching Populace doesn't know the "company line".

 

I generally loathe nano's, and I'll guess in my entire Geocaching career, I've found 5 or 6 blinky nano's. But you know what? The very last one I found, about a year ago, attached to a sign along a bike trail was properly listed as a micro. And there were at least 3 logs before mine correcting the cache owner that the cache was a nano, not a micro. :blink:

Link to comment

I know that there have been issues when GS *did* update the GPX schema which caused some GPS units to brick, but at this point all we really have is speculation that things would start "breaking all over the place" if the value for the Groundspeak:container element was "Nano" rather than one of the de facto standard strings. Jholly reported that it doesn't break a Garmin Etrex 30. I can test it on an Oregon 450 tonight. Anyone else want to chip in?

I have an old Magellan Triton sitting in a box at home. I'll break it out tonight and see what happens just for kicks.

 

...that is, if I can remember how to work it! I'm so used to my touch-screen Garmin now...

Link to comment

I know that there have been issues when GS *did* update the GPX schema which caused some GPS units to brick, but at this point all we really have is speculation that things would start "breaking all over the place" if the value for the Groundspeak:container element was "Nano" rather than one of the de facto standard strings. Jholly reported that it doesn't break a Garmin Etrex 30. I can test it on an Oregon 450 tonight. Anyone else want to chip in?

I have an old Magellan Triton sitting in a box at home. I'll break it out tonight and see what happens just for kicks.

 

...that is, if I can remember how to work it! I'm so used to my touch-screen Garmin now...

 

I downloaded the GPX for a local cache, edited the container element and copied the GPX to my Oregon. Here's a screenshot

 

IMG_0865.jpg

 

 

Link to comment

I assume the reason people want to find the nanos is so they can be filtered out of pocket queries. In theory it could be used by someone writing a query that said "show me all the nanos I haven't found within 50 miles of home" but frankly it's hard to see very many people doing that.

 

I find it quite remarkable that as the game "evolves" (I use the term loosely) we seem to have more requests for filters to get rid of the new things. Whether it's the proliferation of caches that require use of specific gadgets in the field, be they Chirp, NFC, or whatever else, power trails, nanos, it does seem like there's at least some desire to go back to Ye Goode Olde Dayes, when caches were big enough to contain some swag, actually did contain some swag, were found using a GPS based on a pre-planned decision to go caching, and not just another film pot behind a post found with a phone app based on a sense of "I'm bored, I've got 10 minutes to while away, I wonder if there's anything near where I happen to be right now".

Link to comment
I assume the reason people want to find the nanos is so they can be filtered out of pocket queries. In theory it could be used by someone writing a query that said "show me all the nanos I haven't found within 50 miles of home" but frankly it's hard to see very many people doing that.
FWIW, I've also heard some people mention that they "search differently" for nano-caches than they do for micro-caches. So there is also the "truth in advertising" argument from people who want to know what they're searching for.

 

And similarly, I've heard some people argue that we need an official "nano" size to combat "size creep", where people figure that if a blinker is a "micro", then a film canister must be a "small" and a sandwich keeper must be a "regular" and a quart-size L&L must be a "large".

Link to comment

I have an old Magellan Triton sitting in a box at home. I'll break it out tonight and see what happens just for kicks.

Well, so much for that. I pulled it out, popped open the battery compartment to put in some batteries, and was confronted by leaked batteries. Apparently I left batteries in it a few years ago when I put it in storage, and they've since leaked and corroded anything metal in and around the battery compartment. That GPSr will never fire up ever again. I think I'll clean it up and maybe use it as a container.

 

With size creep, a hollow GPSr would be a regular, right? :laughing:

 

...it does seem like there's at least some desire to go back to Ye Goode Olde Dayes, when caches were big enough to contain some swag, actually did contain some swag, were found using a GPS based on a pre-planned decision to go caching, and not just another film pot behind a post found with a phone app based on a sense of "I'm bored, I've got 10 minutes to while away, I wonder if there's anything near where I happen to be right now".

I ran into a family of brand new cachers yesterday. They had downloaded the intro app on an iPhone and were trying out caching. The cache we met at was their first find, and was a micro (bison tube) on a suburban path between roads. We chatted for a few minutes, and at one point the dad asked if there were parts of town that had bigger caches! I enthusiastically told him that while the more urban/suburban caches are often small containers like the one they had just found, if they went out to some of the bigger, wooded parks in the area, they'd be able to find bigger containers in general. It was refreshing to hear that at least one of them was wanting to find larger containers in this age of micro proliferation. They had kids, too, who I'm sure would enjoy larger containers filled with swag more than a blinky, bison tube, or MKH.

Link to comment

I downloaded the GPX for a local cache, edited the container element and copied the GPX to my Oregon. Here's a screenshot

<snipped image>

I wanted to try out a few things, so I did the same with my Oregon 450.

Here's what it shows for the container size in the list view (it was originally a Regular):

Oregon_nano.jpg

 

To answer Walts Hunting's question, yes, if you filter for only micros*, it finds the cache.

 

I then tried some clearly non-sensical values for the size field, including "Foobar" and "Gibberish". Those were treated as "Large".

 

Based on this difference in behaviour between non-sensical values and "Nano", it looks like Garmin is properly handling the "Nano" value (ie. not crashing) and intentionally treating it internally as a micro, as they should under our current container size system.

 

*there obviously isn't a "nano" option in the filter

 

Edit to add:

Oh, and another thing. Using Oregon x50 software version 5.80, this is what I see on the description screen with the "Nano" value:

oregon_nano_desc.jpg

NYPC, I assume you're running an older version? You don't have the size icons, so it looks like your unit is just showing a text field rather than fitting it into one of the size categories.

Edited by The A-Team
Link to comment
I assume the reason people want to find the nanos is so they can be filtered out of pocket queries. In theory it could be used by someone writing a query that said "show me all the nanos I haven't found within 50 miles of home" but frankly it's hard to see very many people doing that.
FWIW, I've also heard some people mention that they "search differently" for nano-caches than they do for micro-caches. So there is also the "truth in advertising" argument from people who want to know what they're searching for.

 

I'll tend to search differently for nanos as well. If I see the cache is a film pot on a guard rail I'll probably at least have a cursory look for it. If I get there and realise it's a nano, chances are I won't even bother to look.

 

Realistically I think it's inevitable people look for things differently. There are places you can hide a nano that you just couldn't hide a film pot, places you could hide a film pot that you couldn't hide an ammo can, and so on. I'm sure I'm not surprising anyone there. So just as it's irritating to find someone listing their cache as "small" when they mean it's a film pot so it can be irritating to find something listed as "micro" when it turns out to be much smaller than expected. Yes, I know it's technically the correct size option, it's just nice to at least have an idea what sort of container is hidden.

 

And similarly, I've heard some people argue that we need an official "nano" size to combat "size creep", where people figure that if a blinker is a "micro", then a film canister must be a "small" and a sandwich keeper must be a "regular" and a quart-size L&L must be a "large".

 

I must admit I prefer it when people use the ? size option for nanos. It's not technically accurate but as soon as I see that size I know it's almost certainly going to be a nano.

Link to comment

...it does seem like there's at least some desire to go back to Ye Goode Olde Dayes, when caches were big enough to contain some swag, actually did contain some swag, were found using a GPS based on a pre-planned decision to go caching, and not just another film pot behind a post found with a phone app based on a sense of "I'm bored, I've got 10 minutes to while away, I wonder if there's anything near where I happen to be right now".

I ran into a family of brand new cachers yesterday. They had downloaded the intro app on an iPhone and were trying out caching. The cache we met at was their first find, and was a micro (bison tube) on a suburban path between roads. We chatted for a few minutes, and at one point the dad asked if there were parts of town that had bigger caches! I enthusiastically told him that while the more urban/suburban caches are often small containers like the one they had just found, if they went out to some of the bigger, wooded parks in the area, they'd be able to find bigger containers in general. It was refreshing to hear that at least one of them was wanting to find larger containers in this age of micro proliferation. They had kids, too, who I'm sure would enjoy larger containers filled with swag more than a blinky, bison tube, or MKH.

 

That's always encouraging. It's hard to see children finding much pleasure in looking for film pots when compared to finding a decent size box with a few swaps in it.

Link to comment

I downloaded the GPX for a local cache, edited the container element and copied the GPX to my Oregon. Here's a screenshot

<snipped image>

I wanted to try out a few things, so I did the same with my Oregon 450.

Here's what it shows for the container size in the list view (it was originally a Regular):

Oregon_nano.jpg

 

To answer Walts Hunting's question, yes, if you filter for only micros*, it finds the cache.

 

I then tried some clearly non-sensical values for the size field, including "Foobar" and "Gibberish". Those were treated as "Large".

 

Based on this difference in behaviour between non-sensical values and "Nano", it looks like Garmin is properly handling the "Nano" value (ie. not crashing) and intentionally treating it internally as a micro, as they should under our current container size system.

 

*there obviously isn't a "nano" option in the filter

 

Edit to add:

Oh, and another thing. Using Oregon x50 software version 5.80, this is what I see on the description screen with the "Nano" value:

oregon_nano_desc.jpg

NYPC, I assume you're running an older version? You don't have the size icons, so it looks like your unit is just showing a text field rather than fitting it into one of the size categories.

 

Looks like I'm running version 4.52 (what it came with when I bought it). I don't know what other "geocaching friendly" GPS devices use to represent the size value. If it just uses text field, there likely wouldn't be any issues, but if it uses an image as yours shows, it would have to check the value of the string to determine which image to render, and that's what could break. It's interesting that version 5.80 accurately displays "micro" when the text is nano and large for non-sensicle values. It seems to me that is should be display "unknown".

Link to comment

Here are the results of the change on my Delorme PN-60w. The Title page lost the graphics and now only displays dashes, but the Description page shows 'Size:Nano'. To get the Title page to display properly on this GPS it would require a firmware revision, but at least it didn't break. If this is the case for other manufacturers then asking all of them to make a firmware change may be too daunting of an effort to undertake.

 

5a0350ae-1fe8-42c9-af9d-e0fb7cabfd2b.jpg

 

The geocache size descriptions (Help Center) rank sizes by volume, from Large (20 liters) down to Mirco (less than 100 ml or 0.1 liters). That's at least one order of magnitude change per rank. This would qualify Nano as a separate size. A typical Nano is 11mm dia. x 13mm long = 1235 mm3 = .0012 liters (1.2 ml) or about two orders of magnitude less than a Micro size.

 

BTW, is 'Regular' a size? :)

Link to comment

It is nice that they show it but you still have to set the filter to Micro on the Garmin which kind of makes the change useless since the desire is to filter for nano's to deal with them.

 

If GS implemented a Nano size, one of things they'd want to do is add a "Nano" size on the pocket query page. That way could specifically include or exclude nanos in the GPX file that gets sent to your GPS. Even if a GPS vendor doesn't update their software to that "Nano" is a filter option, it would't brick the GPS because it's not included in a select list.

 

 

Link to comment

And similarly, I've heard some people argue that we need an official "nano" size to combat "size creep", where people figure that if a blinker is a "micro", then a film canister must be a "small" and a sandwich keeper must be a "regular" and a quart-size L&L must be a "large".

 

^^This.

 

So many times I've gone to get a small, and it ends up being an LPC. I think adding nano would help put an end to this.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...