Closed Akarys42 closed 1 year ago
Using the term "launcher" here is a bit confusing, I was wondering what MultiMC/Prism/etc had to do with this. Later in the document it mentions loader, maybe just use that everywhere?
Using the term "launcher" here is a bit confusing, I was wondering what MultiMC/Prism/etc had to do with this. Later in the document it mentions loader, maybe just use that everywhere?
It was a typo, fixed in 04f42cf
This sounds super reasonable but I do raise a minor concern: would there be any deduplication mechanism on the server side?
I ask because I have multiple Quilt instances on my launcher and they do not share folders, I can foresee my instances pinging the Quilt servers more than once per month. I don't want to artificially inflate the numbers, but I presume this is a common occurrence across tinkerers and developers as well as people who play separate mod packs, given the popularity of launchers that separate instance folders by default, such as MultiMC and derivatives (like Prism).
@hibiii Since the RFC mentions a ...a standard persistent location
I assume that means something like <user>/.quilt_loader/beacon.txt
, rather than in the instance folder itself. As such we wouldn't need to deduplicate requests on the server.
Yes, the goal is to have the persistent file be user scoped when possible
If we're already storing the last sent month in a file, would it be possible to add that as an opt-out method as well? I.e. if the content of the file is not a number, but "opt out"¹ or similar, just abort like if the env variable was set.
¹ Though aborting should be what happens on any error condition anyway (such as failing to read the month), I think it should still be explicitly mentioned
We will not implement that, to reduce the likelihood of an external tool deciding to opt-out for the user without their approval. An invalid date inside the file will be ignored by the loader and the signal will be sent as normal, and the date fixed.
something like
<user>/.quilt_loader/beacon.txt
about this implementation detail:
It would be nice if it would respect the XDG specification, so that it ends up in something like ~/.cache/quilt_loader/beacon.txt
, as that would keep the home directory free of any clutter. Idk if this should be put in the rfc directly or not.
It would be nice if it would respect the XDG specification, so that it ends up in something like ~/.cache/quilt_loader/beacon.txt, as that would keep the home directory free of any clutter. Idk if this should be put in the rfc directly or not.
Good point! Although I think this would end up in XDG_CONFIG_HOME
(~/.config
) instead.
I appreciate the concern, although that's an implementation detail, it doesn't need to be on the RFC.
We will not implement that, to reduce the likelihood of an external tool deciding to opt-out for the user without their approval.
There should probably be a way to opt out still
We will not implement that, to reduce the likelihood of an external tool deciding to opt-out for the user without their approval.
There should probably be a way to opt out still
The PR describes ways to opt out, just not in a way that an external program can make the choice for the user.
Final Comment Period ends on June 14th.
How would this work with per-instance sandboxing? Loader presumably wouldn't just get write access (if any access at all) to a global ~/.config then.
Instance sandboxing will most likely have to give the game access to a shared global folder. We can adjust once that's defined.
This RFC describes a privacy-friendly mechanism through which the loader can signal themselves as an active user, in order to provide a MAU (Monthly Active User) metrics.
If implemented, an accompanying blog post will be published before release, clearly explaining the process and opt-out methods.
This RFC as been validated by the Legal Team as not requiring a privacy policy change.
Preview