_Opening as per chat with @bhousel_
Trying to add a new note on the dev server fails, as it continues to ask for authentication and doesn't ever create the note.

Thanks @JamesKingdom - the issues you're seeing might be related to the OSM server move happening now. I'd like to wait a few days to see if things resolve themselves.
@JamesKingdom : could you maybe post the full URL you're using in order to reproduce this issue? AFAIK the dev server didn't move, so I'm wondering if this might be something else.
@mmd-osm Just go anywhere while using the dev server and try to create a note.
First of all, the issue is unrelated to the server move.
Reason is that the iD OAuth application on the dev instance hasn't been registered with "modify notes." permission.
The following screenshot lists all possible permissions for new OAuth apps on the left hand side, and on the right hand side the ones I'm confirming as an iD user. Clearly, "modify notes." is missing here.

As a result, there's a HTTP 403 Forbidden error when creating notes, as the user won't have the permission to do so on the dev instance. This is totally fine from a Rails pov, it's exactly how it should be. OAuth app registration needs to be fixed here to include the missing "modify notes" permission. Once that is in place, a user can finally grant this permission to iD and the whole thing should work.
Note to self: use this button in the status bar to switch to the dev instance: 
Just flagging that this seems to be an issue on the main OSM server also, related to how openstreetmap-rails preauthenticates iD in the iframe.. cc @tomhughes
Concerning the dev instance, I guess someone at Mapbox originally registered iD as back in 2012 at a time when "modify notes" wasn't available yet. That's not too bad, as that permission can still be added now by simply logging on the dev instance and enabling "modify notes" for the registered app. Not sure how this would affect existing iD users, for new users, it should help.
Maybe it would be useful to query a user's permissions first, and disable some features, if the respective permission hasn't been granted (such as "allow_write_notes"):
GET /api/0.6/permissions (as authenticated user!)
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="OpenStreetMap Server">
<permissions>
<permission name="allow_read_prefs"/>
<permission name="allow_write_prefs"/>
<permission name="allow_write_diary"/>
<permission name="allow_write_api"/>
<permission name="allow_read_gpx"/>
<permission name="allow_write_gpx"/>
<permission name="allow_write_notes"/>
</permissions>
</osm>
Yep @mmd-osm - I forgot to followup to my comment above that @tomhughes already fixed this on the live osm. He can probably do the same for dev too when he has some time, but there's no rush.
also, @JamesKingdom when you place notes, do they appear in a different place than where you click? If so, this is another issue to address.
I think this should be fixed on the dev server master instance now.
Just tried it via http://preview.ideditor.com/master -> switch to dev.
When logging on to the dev instance, I'm getting the following popup without "allow_write_notes" on it:

I'm talking about the editor built in to https://master.dev.openstreetmap.org/ which is called "iD" with a capital so whatever that URL is doing it is not using the same client application.
Indeed, the master instance on dev works with the built in editor. preview.ideditor.com uses the following oauth keys/secrets for the dev instance, but I don't know under which user they have been created, presumably someone at Mapbox as mentioned earlier.
'urlroot': 'https://api06.dev.openstreetmap.org',
'oauth_consumer_key': 'zwQZFivccHkLs3a8Rq5CoS412fE5aPCXDw9DZj7R',
'oauth_secret': 'aMnOOCwExO2XYtRVWJ1bI9QOdqh1cay2UgpbhA6p'
preview.ideditor.com is the main test site for iD, and gets updated with every commit on the iD repo, even before a new iD version gets merged into the osm site.
I've fixed that application record and associated tokens now.
@tomhughes : many thanks, this works now as expected!
@JamesKingdom : I think we can close this one now, right?
This problem is fixed, thanks @tomhughes! :+1:
Most helpful comment
I've fixed that application record and associated tokens now.