Import/Export/Sync quest presets to other devices

[biketeur]

Ich habe jetzt auf meinem Smartphone mit einigem Zeitaufwand etliche neue Quest-Auswahllisten erstellt. Diese würde ich auch gerne auf meinem Tablet benutzen. Wie bekomme ich sie übertragen? Könnte dies SC zukünftig automatisch erledigen?

[wielandb]

This would be hard to accomplish in a traditional way, where settings are cloud-sync'ed, as StreetComplete does not have any proprietary cloud-infrastructure it communicates with on purpose.

My idea to implement such a functionality would be: Densely encode information about quest priority and activation status (and maybe: all settings?) into a string that can be shown on the device as a QR-code, which can be scanned on a second device to import the settings. This information could not only be rendered as a QR-Code, it could also be shared as a string, wich would not only give the possibility to move settings from one device to another, but would also enable people to share quest presets with one another.

[matkoniecz]

In theory https://wiki.openstreetmap.org/wiki/API_v0.6#Preferences_of_the_logged-in_user can be used

[HolgerJeromin]

related #3034 which was about saving/restoring a quest config with a name on the device itself.

[mnalis]

I agree that would be very useful, especially now that we have quest presets!

I'd actually prefer simple Import from file / Export to file instead of (or in addition to) using any cloud-syncing because:

• it is universal; and created files can then be used locally, or shared any way one likes (via cloud solutions, e-mail, or even offline via bluetooth etc).
• it allows use case like "In this situation, I'll export, add/remove/resort some quests from this preset, do what I wanted to do, and then import to restore state" (without import/export, one would destroy existing preset, or would have to painfully create new one which is very similar to old one). It would be especially handy as we don't currently have the option to make a copy of quest preferences (as has been suggested before (#1654 (comment) and #3034 (comment) come to mind).
• I have several instances of SC (for actual use / testing / debugging) and I'd like to avoid one possibly interfering with another (which the automatic-cloud-sync solution would do). Not many people are in this category, that is true, but it comes for free if import/export via files is implemented.
• if the files come in some human readable / general computer usable format (like JSON, or CSV) it has the added benefit that the user can do other stuff with them (like doing global search/replace to enable/disable some quests in all presets etc)

[westnordost]

Import from file is not going to be very useful because the most important step - the sharing itself - is left to the user.

People who want to share their presets are likely but not necessarily near each other. So bluetooth would be an idea, but QR code would be even better if it worked out because a QR code does not require the people to be close to each other - it could be prepared by a person in advance and then everybody can scan it.

Not sure if the preset data can be compressed enough so that the QR code retains a managable size. It would need to contain:

• protocol+path, e.g. "streetcomplete://addpreset"
• name of preset
• quest type (names??) that are activated
• quest type (names??) orders

Maybe this data can be compressed by adding a field for the streetcomplete version, i.e. one QR code only works if everyone has the same version. So instead of quest type names, indices can be used (because the order of the quest types in the quest type registry will be the same).

[westnordost]

So for the record, I see two use cases here:

• a user wants to copy his preset to another device
• a user wants to share his preset with others, e.g. on a mapathon or other social event

[matkoniecz]

http://qrcode.meetheed.com/question7.php

Standard QR Codes can hold up to 3Kb of data.

so it likely should be enough

It would need to contain:

I would also include version of format so it could be easily changed in future, while retaining backward compatibility.

See also earlier WONTFIXed #1393

[smichel17]

From https://github.com/streetcomplete/StreetComplete/issues/1393#issuecomment-491619515,

A QR code is technically doable, however, it would require a new permission to be conveniently usable - the camera.

Depends on your standard of convenience. One way to do it would be to encode the settings as a uri. Then you could register SC as a handler for that uri. So you could scan the QR code with any app... OR copy the uri directly and open it as a link. Bonus points if it's the url of a website which can explain what it is and how to use it (and render as a qr code).

[matkoniecz]

it would require a new permission to be conveniently usable - the camera.

Camera is already anyway requested for attaching images to notes.

[mnalis]

Import from file is not going to be very useful because the most important step - the sharing itself - is left to the user.

@westnordost After saving a file, SC could present user with standard "share" icon for sharing the file further (or android share functionality could be invoked automatically after the file was saved - OsmAnd does that for its settings backup, for example).

And when share functionality is invoked from the app (either automatically, or by a manual click) one can share the file via any of many supported options (e-mail, social networks / chat apps, bluetooth, NFC, QR code, cloud storage, ShareViaHTTP, etc.)

So for the record, I see two use cases here:

Well, I've mentioned 4 other use cases earlier, and out of those four, QR partially solves one (and even that one, only with much reduced functionality).

There is also a "plain backup" use case (eg. user needs to uninstall the app the install previous version or beta version with different key, or as a protection against phone crash etc) - QR does not help there either.

• a user wants to copy his preset to another device

QR would work there, but only if both devices are physically present (and with non-empty battery) in the same place at same time, though.

• a user wants to share his preset with others, e.g. on a mapathon or other social event

Even there, simply sharing to their common communication channel (probably group chat app or social network) is much more convenient then having people come one by one to the coordinator to scan QR on his/her phone. Especially in this times of social distancing, when mapathon group could be easily separated by distances / starting in different places.

[smichel17]

Well, I've mentioned 4 other use cases earlier, and out of those four, QR partially solves one

Huh? QR is just a storage format. If it encodes a URI, especially if SC exposes the URI directly as text, it seems like they are all covered.

• a user wants to copy his preset to another device
• a user wants to share his preset with others, e.g. on a mapathon or other social event

I'm not sure why you think using a QR code excludes using common communication channels. In these cases, you can generate the QR code and send it to yourself via email, text, social media, copying the URI and saving it in a file, etc. If it is a URI, the recipient doesn't even need to have a QR code scanner installed, they can simply click the link from their phone, open it in SC, and accept the prompt to import those presets.

edit: many of these are true even if SC does not provide a share option! You can take a screenshot and share that via whatever channel.

[mnalis]

@smichel17 well, all QR usages I've seen have been of the form that QR app starts camera and lets me take a picture of some QR code, and then decode it and call appropriate app according to QR content. If it would work so as other apps, then all the use cases I've mentioned that involve just my phone would be impossible, because I cannot point my phone camera to my own screen.

If however scanning QR could would offer me the choice of either starting camera or opening a file from storage, then I guess QR code could be used as a clumsy way of file storage. It would have few disadvantages, IMHO:

• SC would probably need full storage permissions (in order to access my Screenshots pictures folder, so I could scan code I just made in other version of the app before I uninstalled/downgraded SC, for example)
• it would require extra (QR) libraries to be imported in SC, thus increasing its size and adding more dependencies (and duplicating already existing share android functionality)
• And it would be more clumsy to use:

eg. see this comparison if one wanted to send SC presets via e-mail:

If using regular file with Android share functionality, workflow would be:

• In SC, click export - presets-20211120_024130.sc (or whatever) text file is generated, and share functionality invoked automatically for it
• sender chooses for example 'K-9' e-mail client from the list
• presets-20211120_024130.sc file is attached automatically, so one just enters recipients and click 'send'
• recipient receives mail and clicks on attached export file, and Android automatically asks with which app to open (probably offering only SC for *.sc files?)
• recipient chooses to (probably always) open it with SC, which automatically imports the preset

If using QR code functionality embedded in SC:

• In SC, click export - QR code is generated and displayed on screen
• make a screenshot (to save it to disk)
• exit SC and go back to launcher screen
• start K-9 e-mail client from launcher
• click K-9 icon to create new mail
• click K-9 icon to add attachment manually
• navigate to Screenshots directory in file manager that opened automatically
• find the correct screenshot to attach (probably involves changing sorting by time, scrolling to the bottom of the list, etc) and click it
• enter recipients and click 'send'
• recipient receives mail and clicks on attached Screenshot-xxxxxx.png file containing QR code
• QR code is displayed on screen; and recipient chooses to save the file to disk
• recipient exists K-9 e-mail client and goes back to launcher
• recipient starts SC from launcher
• recipient chooses import QR functionality, and chooses from file (instead of from camera) sub-functionality, which opens file manager
• recipient navigates to directory containing K-9 saved attachments
• recipient finds the correct QR screenshot (probably involves changing sorting by time, scrolling to the bottom of the list, etc) and click it
• SC imports the preset from selected QR picture .png file

Perhaps the QR version workflow could be somewhat improved from that detailed above (if using some kind of URI as you say, I'm not fully versed how that works), but I'm afraid it would still be less user-friendly compared to standard Android share functionality? Or perhaps I've misunderstood how it would work; could you show me step-by-step example how you envision it working (like I did above for e-mail example)?

[smichel17]

Sorry for the excessive <details>. This is all just clarification, so if you already understood, you can probably skip this comment (@westnordost).

I have some issues with your comparison

• exit SC and go back to launcher screen
• start K-9 e-mail client from launcher

Steps like this, I find to be quite unimportant. Exporting and sharing quest presets between devices is not intended to be something that you do all the time, so a step as simple as change to another app, once doesn't require a press-by-press list of all the steps required to do it. I change apps all the time; it really isn't a burden. Plus, I find it a little disingenuous, since you've (correctly!) skipped the similar steps for "open K9 mail, find the mail, click on the attachment" in your "regular file" example.

• find the correct screenshot to attach (probably involves changing sorting by time, scrolling to the bottom of the list, etc)

This is definitely the hardest step, as it might not be clear where the screenshot is saved. However:

1. My point about a screenshot was that it works even if SC does not provide a share function. More likely, it would be "tap the share button on screen and SC shares the image via standard android channels, where you can pick K9 (or whatever other app).
2. My phone's screenshot function shows an overlay afterwards with a share button, so even in the screenshot case, it would not be as many steps as what you've described.

Re-explaining in more detail / hopefully more clearly

How the uri would work

Apps in Android can register themselves as handling certain URIs. For example, OctoDroid is a GitHub client for Android. When I'm in my email and I tap a github.com uri, I'm given the choice to open it either in my browser or in OctoDroid. That's because, in its AndroidManifest.xml, it declares that it handles https://github.com URIs.

StreetComplete could this, so whenever you click a link that begins with https://westnordost.de/presets/v1/, you would have the option to open that uri in StreetComplete. The presets would be serialized to the uri after that prefix (so you'd end up with a very long uri). When you open such a uri in StreetComplete, it would parse it and offer to import those presets.

For example

Disclaimer: This is just to illustrate the mechanics involved, NOT the actual serialization format, which I would need to think more about.

https://westnordost.de/presets/v1/?Everything=A,B,C&Important=A,-B,C

Explanation:

• To make this simple (and short), let's imagine StreetComplete has only 3 quests, A, B, and C.
• …And that I have only two presets:
  • Everything has all three quests enabled, in alphabetical order.
  • Important has only A and C enabled, in reverse alphabetical order.

It's basically all the contents of the export file shoved into a URI, and instead of being identified by the file extension, it's identified by the string prefix.

Steps to use the URI version (nearly-identical to your file version)

• In SC, click export - https://westnordost.de/presets/v1/?Everything=A,B,C&Important=A,-B,C (or whatever) URI is generated, and share functionality invoked automatically for it
• Sender chooses for example 'K-9' e-mail client from the list
• https://westnordost.de/presets/v1/?Everything=A,B,C&Important=A,-B,C text is pre-filled automatically into the body, so one just enters recipients and click 'send'
• Recipient receives mail and clicks on the URI in the body, and Android automatically asks with which app to open (browser or StreetComplete)
• Recipient chooses to (probably always) open it with SC, which automatically imports the preset

For the final step, probably there should be a confirmation step here, for the file version, too. And, if the recipient instead chose to open in browser, we could put up a page on https://westnordost.de/presets/v1/ with instructions explaining what this is and how to import it.

Note: URI vs URL

I'm saying uri only because we could do streetcomplete:v1:Everything=A,B,C&Important=A,-B,C. They'd be shorter and only SC would open them, at the cost of not being able to show an explanation page when someone opens it on a desktop, iPhone, or Android (without SC installed). I favor the https version.

How a QR code fits in

A QR code is just a visual encoding of data. We'd use the QR code to encode the URI above. There are some codes for example below. You can try them out by using this app: https://f-droid.org/en/packages/com.example.barcodescanner/ Note: the app is able to scan an image, so this is a way to extract the uri from a screenshot.

Technically…

You wouldn't even need a QR code scanner included in SC, because the linked app will extract the uri; when you click to open the uri, Android will prompt to open in SC, same as in the email example above. But it would still be good to include a scanner, since I wouldn't expect everyone to have a QR scanner installed.

QR: Example uri from this post

QR: Link to your comment (that I'm replying to)

[mnalis]

Using URI prefix instead of file is just fine, provided we can fit all current and future data in much more limited space, I have no problems with that at all.

Oh, and I have no big problem with QR being displayed in addition to using Android share functionality @smichel17 (it is just unnecessary duplication of functionality IMHO, since share includes QR codes too, at least in my phones, but whatever).

What I was afraid of was that QR was being suggested as a solution instead of Android share functionality, which would severely limit its usability, as detailed earlier (especially if trying to use it on the one device). Nobody happier than me if I misunderstood that, and QR is just intended for being offered as an extra after/before doing Android share. :+1:

[smichel17]

I have "create QR code" in my share menu, but only because I have a QR code app installed (the one I linked earlier). Once SC has the data, invoking the "share" functionality should be trivial, so the exact steps for how that happens isn't something I'm particularly concerned with until we have decided on the bigger-picture UX. Which brings us back to where we were before this side-track, https://github.com/streetcomplete/StreetComplete/issues/3481#issuecomment-962436364:

Maybe this data can be compressed

Here's all the compression tricks I can think of— not saying it's a good idea to use any/all of them (and some are incompatible)

• Define a default order, then only record a diff
• Represent activated separately from order, using 1 bit per quest (bit-packed), based on some fixed order.
  • On a case-by-case basis, try both this representation and a diff, and use whichever is smaller.
  • The reason I say "some fixed order" and not the sort order is that if new quests are always appended, then it would be forward and backward-compatible, since newer versions would use the default for any missing at the end, and older versions would only read as many bits as they have quests.
• Represent each quest as the shortest unique prefix of its name— less compression, slightly more human-editable.
  • Human-editable is useful as an escape valve for power users who want to heavily customize their presets.
• Compress (e.g. gzip/brotli) the whole data part (after the URI prefix); may also need to base64 encode it (or similar), so I'm unsure how much this would gain us.

I think it makes sense to version based on the compression format, rather than the SC version. No reason why a bugfix release should become incompatible with the previous version if nothing changed. It does become something we need to remember to increment, though.

provided we can fit all current and future data in much more limited space

SC does not limit the number of profiles you can create, so it is obviously impossible to fit all possible combinations into a single uri (or QR code, for that matter). It's more about what portion of normal usage we can accommodate and how to handle the case when there's too much data.

I think there's a key decision about our goals here, which will decide which of the tricks above to use:

1. Minimize the number of users who hit the "too much data" edge case, but don't worry too much about the experience of power users who create too many presets.

   • This probably looks like "compress the data as much as possible, and just fail (with an error message) if it won't fit."

2. Minimize the friction of running into the "too much data" edge case, even if that means more people experience it.

   • This probably looks like one preset per URI (or at least the ability to share presets individually). This means we don't need to worry about compression as much, and can prioritize compatibility and maybe human-legibility. Not sure how it fits in with QR codes yet.

So for the record, I see two use cases here:

• a user wants to copy his preset to another device
• a user wants to share his preset with others, e.g. on a mapathon or other social event

Agreed, with one addition: I think I'd want to copy all of my presets to another device, whereas with someone else maybe I just want to share one or two.

So, I think I lean toward solution 2. Or maybe a combination of that (for sharing individual presets with others) and https://github.com/streetcomplete/StreetComplete/issues/3481#issuecomment-958708167 (for syncing all presets to another device).

[mnalis]

I would just add here that if we opt for "regular file + android share" (instead of "URI + QR") we neatly avoid all those problems related to data size, compression etc. (and we still retain QR capability for those presets which are small enough, via android share + QR)

My main issues with trying to compress data in fixed size buffer are IMHO:

• as you note, it will necessarily fail if user has complex enough presets (which is ironically exactly the class of users which would benefit from this functionality the most!)
• it heavily suggests using high compression techniques (like bitmapped arrays) which are version dependent (eg. changing an order of quests, or adding / removing quests at any position but the end of the list make those exports incompatible with other versions of SC, which is IMHO a big problem as it drastically reduces a usability of that feature)
• it makes it much harder (ie. in practice, next to impossible) to view/edit data in any external programs (like plain text editors, which would work just fine with "ASCII file" idea)

[mnalis]

@smichel17 that being said, it that path is taken, exporting only one preset sounds like a better idea:

• it simplifies UI somewhat (no need to add checkboxes for choosing which preset user wants exported/imported, instead just automatically exports from (or imports into) currently selected preset)
• it allows for less data compression, thus allowing more features (eg. preset export can be made compatible with different versions of SC which have different quest, and quest ordering could be preserved in the export, etc.)
• it only slightly penalizes power users (ie. they need to export/import dozen times if they want to backup all presets, instead of the other idea which would leave them completely unable to utilize this functionality, which would be quite horrible)

[mnalis]

(related: https://github.com/streetcomplete/StreetComplete/issues/3034)

[vizsim]

Hi, I am planning to use StreetComplete in a university course (something like "Digitization in bicycle planning") to show how bicyling infrastucture in OSM is tagged and how SC allows rather easy contribution to OSM in general. To share my preset of (bicycle-related) quests to the students, I would love to see this issue closed. :) Or is there any other way to share custom presets by now?

[westnordost]

No, there is not any way to share presets. This ticket is very low priority for me right now, but if someone else wanted to implement it, it should best be done with the QR code approach mentioned here.

[mnalis]

@vizsim as a quick workaround in your specific case, if you can't wait for feature to be implemented, it should not be too complex to present instructions to students to:

• install StreetComplete from https://f-droid.org/repo/de.westnordost.streetcomplete_4101.apk (or other options)
• click hamburger, Settings / Quest selection and display order
• click ⋮ and Deselect all
• click magnifying glass and type cyc
• select all 8 (or how many) purple icons, as they relate to bicycle. (i.e. do not enable motorcycle or recycling ones.)

Sure, it is a few steps more than "install SC, go to this menu and scan this QR code", but not horribly much so - and you can use it today. (It might be a little bit more susceptible to human error, but then again, QR would be susceptible to greasy camera lens, distance, contrast etc. too)

[vizsim]

yes, thanks for the feedback! @mnalis thats my plan now. acually I chose like 33 quest since some other quests also effect cycling somehow. I am pretty happy with this approach now, however, thought it my be helpful to share my use case. thanks anyways for all the work you contribute here!

[mnalis]

@vizsim if you're dealing with higher number of quests, another alternative is forking the project and editing app/src/main/java/de/westnordost/streetcomplete/quests/QuestsModule.kt to only have quests that you want. You can even have GitHub compile that version by simple click (so you don't need to be android developer - I use that feature myself, and my android programming knowledge is limited to copy/pasting thinks and hoping they work :smiley:), and then distribute resulting .apk to your students.

But I do agree that this would be quite useful feature to have in mainline. If anyone decides to give it a go at implementing this in any shape of form, I'm quite willing beta tester.

[westnordost]

A little more thought how the URL (that goes into the QR code) could be structured to be as short as possible:

All quests in one SC version have a default sort order, so, each quest can be assigned an ordinal. This requires that QR codes are only compatible across the same version, so the current app version must be part of the QR code

Short enabled quests + order

1. (URI schemes in) QR codes are most space efficient if only "0–9, A–Z (upper-case only), space, $, %, *, +, -, ., /, : " are used, see wikipedia.
2. It is even more space efficient to only digits, even in parts of the whole URI. So, the ordinals could be expressed in base 9 and "9" be used as a separator
3. Usually, the use case of sharing quest presets would be to share an (extremely) limited number of enabled quests, so it's best to just enumerate only those quests that should be active in the order in which they are sorted.

Example

STREETCOMPLETE://PRESET/4101/192939495969798910911912

The above means:

• Preset compatible with app version code 4101 (v41.0)
• the first 11 quests are enabled and sorted in that order. (Remember, the "9" is the separator)

Notes

• It's complicated or not possible to "restore" the correct order of the quests as in the source preset. The enabled quest types will just be sorted in the front
• QR codes where a lot of quest types are activated could get very long. The longest possible URI (all quest types activated) would be

Carbon copy enabled quest types (no order)

• The URI would then always have the same length (number of quests + a little overhead).
• it looks like QR code sections that only consist of digits can be encoded more efficiently. The below QR code is only 30% bigger than the above even though it cannot get bigger than that
• the URI could just be a long string of 0s and 1s, each denoting whether the individual quest is active or not. To make it even shorter, the "base 2" string can be converted to base 10

Example

STREETCOMPLETE://PRESET/4101/1907419645122502569235665619818048563882

Note

So this is only going to copy a preset 100% IF the feature is removed that the user can change the order in which quest types are shown on the map, which I have been thinking about for a long time anyway. Some power users have opposed the removal of that feature back then. Not sure if this changed now and/or if this feature is really still used.

Carbon copy enabled quest types + order

The last possibility would be the same as above but append any changes in quest type order the user made. This is basically the same format as in the database and would be most easy to parse.

Format of the latter section: ordinal of quest type that should be in front "+" ordinal of quest type that should be after

Example

STREETCOMPLETE://PRESET/4101/907419645122502569235665619818048563882/10+1-9+3-5+8-58+1

Notes

This format has the potential to grow (indefinitely) big because there is no limit on the re-orderings a user can make. So there needs to be some kind of checks and balances that prevents this somehow

[mnalis]

My comments:

• I myself still use ordering functionality and find it very useful. (though I usually do not have a huge number of quests with changed positions, usually about 3-10 per preset)

• most of my use cases revolve around using import/export to "share" quest presets with myself, most often on the same device. Thus, if using QR codes, I would need functionality to scan QR from picture gallery (i.e. not only using camera app.) (I would also obviously need ability to save QR code to file of course, but that can be worked around with standard android screenshot if not present in-app)

• it might be useful to also save preset name when exporting to QR code, and when importing create (or update) preset with that name. Or at least have the name shown in the picture alongside QR code when making screenshot - that would help with above (especially if there is no "save file as" functionality built in the app but one has to create screenshot to save QR code to file), or it would be very hard to distinguish with screenshot corresponds to which exported preset.

• I would suggest to try to use version-independent mechanism for generating QR code. For example, one could use two alphanumerics to define unchangeable quest ID in SC source (e.g. lit quest might always be defined as A0, surface as A1, smoking as BD etc.). That allows for 1225 different quests, which should be enough for foreseeable future, as we probably don't want to go above 990 quests or so anyway (to keep URL below 2000 chars, see earlier discussion about possible limits).

  examples

  • ordering of lit+surface would be encoded as STREETCOMPLETE://PRESET/A0A1

  • ordering of surface+lit would be encoded as STREETCOMPLETE://PRESET/A1A0

  • just smoking would be encoded as STREETCOMPLETE://PRESET/BD

  • ordering of surface+smoking+lit would be encoded as STREETCOMPLETE://PRESET/A1BDA0

  • longest QR code (of all current 154 quest) with any ordering would be encoded in 332 bytes as: STREETCOMPLETE://PRESET/0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A encoded as

  • note that while alphanumeric QR encoding indeed requires 5.5 bits instead of 3.33 for numeric encoding, it also stores more data per character, so it evens out.

  Such encoding would have following advantages:

  • no need to encode version number, as it is version independent. Once smoking quest is identified as BD, it will be so in all versions. (If someday we need more than 990 quests, we could simply use /PRESET2/ or similar and remain backward compatible)
  • it preserves ordering too, with fixed cost (not growing depending on number of order changes)
  • it is version independent - you could make export in SC 87.2 and import it in older SC 43.0 (but obviously you wouldn't be able to solve quests which didn't exist yes in SC 43.0 :smile:, but all other would be preserved). I find this quite important as power user (even when sharing with others, it is not reasonable to expect they all run the same version, depending on the play store they use etc).
  • QR remain simple if you only enable few quests (as best of the suggestions above do too)

TLDR; if I could "make a backup of my presets, then uninstall the current version and install older version, and still be able (without requiring extra hardware devices) to import presets with their ordering", then it would likely have all functionality to also fulfill all my other use cases too.

[matkoniecz]

I am iffy on incompatibility between versions - this is quite unexpected and will be really confusing and would make some use cases impossible ("use this code to map wheelchair specific data" would need to be constantly updated).

[westnordost]

I favor "Carbon copy enabled quest types + order" because

• it is 1:1 how the presets are stored internally, so implementation is simplest. I.e. not doing it like this means that the preset one imports from QR code would be different from the preset one exported to QR code: E.g. all enabled quest types would be sorted in front. Not a big issue for users, but probably for people like @mnalis who'd want to use that feature to "save/restore presets to disk"
• it mostly has a constant (very compact) size, independent on how many quests are enabled and only growing (slowly) when the user reordered a lot of quests

The requirement on that it only works if the source and target device uses the same app version can be removed by doing (something similar to) what @mnalis proposed: In QuestsModule, every quest type must be assigned a unique (integer) id. Either by duplicating the list but the order of that second list is guaranteed to never change or by e.g. changing the constructor parameter of QuestTypeRegistry to quests: List<Pair<Int, QuestType<*>?>>

[HolgerJeromin]

It would be nice if the user can copy and paste the quest string somehow. So we could publish a setting via messenger or webpage. QR Codes are nice but quite cumbersome if you have the image in another App (screenshot, browser, chat) and not in front of you.

This would reduce the need to fetch from gallery for @mnalis use case.

[IzzySoft]

Just wondering: Will something like this be implemented in the "foreseeable future"? It would also be useful e.g.

• as Backup (to be restored e.g. after a factory reset)
• as xfer/exchange when switching to/from the EE version on the same or a different device

In both cases, if the approach is a QR code it would need to be stored and copied, then displayed from a different place to be able to scan it back. It would hence be nice to have a "file export" (e.g. JSON) as alternative – which would e.g. make the exchange with EE on the same device much easier (especially if no other device is available to show the QR).

[westnordost]

Yes, very likely in the next months