Add a suffix to text of anonymous notes

[deevroman]

Description

Partial solution #3932

All anonymous notes are suffixed with "via OSM website." Similar to StreetComplete (without hashtags :)

2026-01-31.00.42.50-optimised.mp4

Just don't tell me we need to implement real tags and note versions in the data model. That's a huge overengineering for a simple problem. Metainformation in the text of notes does not bother anyone except the authors of notes who suffer from perfectionism.

Hashtags and their equivalents already work great in other apps and help resolve notes. Let's first explore how website users use notes, and then consider what changes we need to make to the data model.

We'll also finally find out if there are apps that use anonymous notes via the API.

[tomhughes]

Maybe when you're ready to accept review comments somebody will be prepared to review your work.

[deevroman]

It seems you misunderstood «Just don't tell me we need to implement real tags and note versions in the data model»

I was trying to warn you against prematurely dismissing PR by analogy with #3938 because my PR only affects anonymous notes, that irritate the community

[tomhughes]

The point is that I have no idea what my review comments would be if I were to review this but I do know that trying to pre-emptively say that certain possible comments are somehow not allowed is not acceptable as far as I'm concerned.

[1ec5]

For future reference, the text in the PR description reads like a rebuttal or retort. It wasn’t clear who you were responding to, so it took on a more aggressive tone than you probably intended. In general, it is a good idea to explain how your PR differs from previous proposals, keeping the focus on the code and your thought process. You could clarify that the PR doesn’t add extra metadata to the database table and you don’t think it’s necessary for this part of the fix. Also, you could also point out that this PR avoids using literal hashtags, as suggested by the maintainers in the issue.

[gravitystorm]

Just don't tell me we need to implement real tags and note versions in the data model. That's a huge overengineering for a simple problem. Metainformation in the text of notes does not bother anyone except the authors of notes who suffer from perfectionism.

Well then, there's not much for me to say here, is there?

You're proposing adding metadata to the notes, but by cramming the metadata into the note comment field, instead of adding the metadata in a separate field. This is bad engineering, and it just stores up problems for the future.

If we add this now, people will start relying on it (either from reading habit, or through scripts or data processing which parses the note text against a particular pattern to find the information). Other API clients will want to know if they should add a suffix too? What format does their metadata have to follow - are both newlines required? Can you parse out the client information from a given note - or do we need something more recognisable as a separator?

Then when we want to solve the metadata problem properly, i.e. adding metadata as a separate field, we have created headaches for ourselves (do we migrate the existing notes to move the existing metadata to the new fields? Do we have to keep adding the suffix, even when we have the new metadata fields, because some unknown number of 3rd-party systems have been built to rely on the inline metadata?

---

Now you can argue that any of these points are no big deal, but they illustrate the reason that maintainers will push back on your approach. Yes, it's quick to implement. Yes, it avoids learning how to make database and API changes, so it's as low-effort as you can possibly achieve today. But the low-effort is not improving the long-term situation. It's just pushing back the complexity into the future, and in fact adding to the complexity for whoever tries to implement it properly. It's not a first step towards a solution. Adding metadata fields to notes would be easier today, without this PR, than it would be in the future if they also have to consider dealing with how to handle the outcome of this PR too.

Also, adding metadata fields to notes is not some "huge overengineering" project, it's a few database fields and additions to the API. It's the right approach to solving this problem, and this PR is not.

---

As for a review request, I'll do that too:

• This doesn't take into account length limits on the note field, i.e. making sure a user doesn't type too much and then being unable to save after the metadata is added
• There's no clear boundary between note comment and the metadata, for any system that tries parsing it or similar metadata added by other API clients
• There's no tests