Support horizontal emoji composition

[jdherg]

Right now emoji.octopus.holdings only supports vertical emoji stacking. It would be fun to be able to go horizontally as well!

API design question: right now the URLs use / as a row separator and try to treat everything in between a pair of them as a discrete emoji. What should the syntax be for horizontal composition?

UX question: right now the emoji are stacked directly on top of each-other and centered. How should multiple emoji be positioned in the X-axis? What if rows are of different lengths?

[Yuffster]

/tophat/octopus?/tophat/cat&/tophat/dog?

[kamalmarhubi]

+?

[kamalmarhubi]

UX question: right now the emoji are stacked directly on top of each-other and centered. How should multiple emoji be positioned in the X-axis? What if rows are of different lengths?

needs some... research at the source

[cmchap]

How about this: start with the left-most column of emoji, and populate additional columns to the right of that original one. Have columns separated by ? in the URL. Each emoji in the column is populated top-to-bottom. Use x as a placeholder to show no emoji in that location. If all the columns are not of equal length, show empty spaces below a short column.

A benefit of this system is that it preserves the functionality of any existing octopus.holdings links. (Because Cool URIs Don't Change.) In this vein, a single emoji in the url should be shown as held by an octopus.

So here are some examples:

---

The default standard octopus holding a trophy would be http://octopus.holdings/trophy/octopus/

|trophy |
|octopus|

This output also be achieved with the special-case of only one emoji in the URL. http://octopus.holdings/trophy/

---

http://octopus.holdings/[emoji1]/[emoji2]/x/[emoji3]/[emoji4]/?/[emoji5]/[emoji6]/[emoji7]/x/[emoji8]/

|[emoji1]|[emoji5]|
|[emoji2]|[emoji6]|
|        |[emoji7]|
|[emoji3]|        |
|[emoji4]|[emoji8]|

---

http://octopus.holdings/[emoji1]/[emoji2]/?/x/[emoji3]/

|[emoji1]|        |
|[emoji2]|[emoji3]|

---

http://octopus.holdings/[emoji1]/?/[emoji2]/x/[emoji3]/[emoji4]/?/[emoji5]/[emoji6]/[emoji7]/x/[emoji8]/

|[emoji1]|[emoji2]|[emoji5]|
|        |        |[emoji6]|
|        |[emoji3]|[emoji7]|
|        |[emoji4]|        |
|        |        |[emoji8]|

[Yuffster]

? as a significant character in the query string might confuse some of the code.

I like using x to mean "nothing here," why not a character that means "new line"?

[cmchap]

@Yuffster I didn't think too hard about which specific characters we use (I just needed something as an example.), so I'm glad you're thinking about code confusion.

Upon further inspection of emoji_map.json, I found that x is already assigned to the ❌ emoji.

That finding led me to think about requirements for our "nothing here" and "newline" signifiers. Here are a few things I think we should consider (in no particular order):

1. Is the signifier already used as an emoji name in the existing emoji mapping? (e.g. x for ❌)
2. Is the signifier already used as part of an emoji name in the existing emoji mapping? (e.g. _ in fork_and_knife)
3. Will the signifier break backwards compatibility with existing octopus.holdings URLs? (e.g. x would disrupt existing URLs that use ❌.)
4. Will the signifier need to be percent-encoded according to RFC3986? If so, are we okay with percent-encoded URLs looking 'less pretty' than a non-percent-encoded URL?
5. Is the signifier in the set of reserved characters according to RFC3986? If so, will this confuse web servers and/or the octopus.holdings code?
6. How similar does the URL look to the typed string on Zulip? ( I believe this was an original design consideration by @jdherg)
7. How easy is it to type the URL? What about typing it on a mobile device keyboard?

With those considerations in mind, I think we should use n for "new line" (akin to the \n newline character).

I had considered using _ for "nothing here", but since underscores are used in several of the emoji names (e.g. fork_and_knife for 🍴) it might get a little visually confusing. I also looked into using - or + for "nothing here", but there are a few emoji names that use those, too (e.g. -1 for 👎 and +1 for 👍). We could use ., since it doesn't show up in any of the existing emoji names, but I don't know if/how using . would affect browsers/webservers/octopus.holdings.

[Yuffster]

As long as the separation character isn't a emoji name itself, like x, and it's clearly separated in it between slashes, using characters that appear in other emoji names shouldn't be a problem.

Assuming the code just does a split on the slashes in the URI path, you'd have each of the names as a separate entity to decode.