Proposal for Messages API about openstreetmap-website HOT 8 OPEN

To prevent bulk messaging, sending a message must be throttled, similar to how changeset submission is throttled.

Mesage sending is already rate limited - has been since 81d47fe with further enhancements in 25510b6.

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

This will definitely be controversial - there have been differing opinions over the years and at one point I understood that the plan was to move in this direction but more recently things have swung back the other way and I know @gravitystorm is not a fan of moving things client side and have the web site work via API calls.

from openstreetmap-website.

We posted a more detailed API draft on wiki: https://wiki.openstreetmap.org/wiki/Messaging_API_proposal

from openstreetmap-website.

I believe we would need to apply rate limiting for sending messages from the API as well. I would also put a limit on some read operations, for example for retrieving the list of inbox messages.

This will definitely be controversial - there have been differing opinions over the years and at one point I understood that the plan was to move in this direction but more recently things have swung back the other way and I know @gravitystorm is not a fan of moving things client side and have the web site work via API calls.

Our intent was to have it there as a proof of concept, hoping it was a good thing to do. If this is against the OSM way, we can leave it out.

from openstreetmap-website.

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. 😄 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.

from openstreetmap-website.

I believe we would need to apply rate limiting for sending messages from the API as well.

Absolutely, the rate limit is is a limit on sending messages and how they are sent is not important so it should apply to the API in the same way it does to sending via the web site.

from openstreetmap-website.

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.

It requires adding a searching functionality to replace Ctrl+F.

from openstreetmap-website.

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. 😄 We already do this for a couple of parts of the website (e.g. Notes) and we're working on specifically undoing this.

Nobody is working on it. Changing things to use the api instead of the db directly or vice versa is going to affect how user blocks work. Currently they cut off the api access.

from openstreetmap-website.

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. 😄 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.

My suggestion was to make use Message API from web site as a proof of concept. I was not aware of (failed) attempts to do similar things in the past. As suggested, we will not use Message API from web site.

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.

Agreed.

Will also change the naming to refer to Messages instead of Messaging.

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

To clarify, the efforts related to this github issue are only with regards to direct messages to and from the users. There is no attempt to (partially) fix the notification of any kind, including the notifications about received direct messages.

• 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.

This is what I had in mind:

• message_consume to be able to read, messages, update their status to read/unread or deleted. Affects only messages owned by the user.
• message_send - to be able to send messages to other users. Affects other users as well.

from openstreetmap-website.