[openstreetmap/openstreetmap-website] Proposal for Messaging API (Issue #4509)

[Andy Allan]

> We plan to work on transitioning OSM web site to use the Messaging API instead of directly accessing the content of the database.

As @tomhughes anticipates, that's a "hard no" from me on this approach. :smile: We already do this for a couple of parts of the website (e.g. Notes) and we're working on specifically undoing this. It's overcomplicated, it's unnecessary indirection and causes way more hassle for little to no tangible benefit. 

So I'm in favour of a Messages API (nb not 'Messaging') but the web interface should continue to be a straightforward server-side-html / html-over-the-wire implementation like the rest of the site.

> In other scenarios, i.e. changeset comments, notes and diary entries activities, OSM website only sends emails to subscribed users.

This is another thing that will need to be clarified up-front. The topics of Messages and Notifications are two different topics. We currently lack a proper Notifications system, and this often leads to confusion between notifications and messages. In particular, since there is a email notification sent for new Messages, and you can respond to that notification and it's treated as a new Message, that's a source of confusion. Additionally, the "Unread Messages" indicator on the site makes people think that it is a "notifications count", when it is not, and we don't have any way to view notifications on the site (e.g. view a list of changeset comment notifications that you have received).

I hope we can build a proper notifications system in the near future, and refactor all our existing event notifications to use it.

In the meantime, it's important that these two topics are understood as being two separate things, and this proposal needs to be updated to clarify that they are different topics to avoid (even more!) confusion when other people read it.

> * one for reading messages, and an additional scope for creating new messages and sending them.

It's worth clarifying which scope you think "change read status" should be included in, I could be persuaded either way.

> In addition, the API provisions for paginating the list of messages.

It might be worth spinning this off into a precursor project - to paginate the existing inbox and outbox implementation. That way, all the complications around cursor-based pagination (see e.g. @tomhughes recent work with diary entries and traces and @AntonKhorev recent work on diary_comments) can be sorted out separately. That will reduce the complexity of reviewing the API implementation.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/4509#issuecomment-1932141784
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/4509/1932141784 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20240207/2d7b3ee0/attachment.htm>