I wanted to share my experience upgrading from the original JSON file to the new schema.

In order to make the upgrade, I used the following resources:

Following the Murmurations Map schema from the MurmurationsLibrary repository, especially the fields descriptions, helped my way through the process.
The JSON Schema validator, feeding it the murmurations_map-v1 schema JSON in the left panel, and my profile JSON in the right panel
curl commands to submit the new profile -- changing the submission URL to .network instead of .tech)

The process was not without flaws:

Somehow the profile generator website refused to validate my form entries without telling me why, which I debugged by doing it manually following the above checklist. But I was already feeling bad being able to claim the existing profile URL and build on top of it -- which I understand the cause, and saw the related issue, and am glad that I could still do it since otherwise it would have been painful to get things going.
Once the profile was uploaded via curl successfully, I could "update" it from the dashboard, but then it keeps telling it's invalid, which puzzled me and prompted me to report here.
Although I understand the need to minimize human resources and focus on building the protocol and related code -- and I must say I like the way this is moving slowly but steadily -- I felt very uncomfortable with having to authenticate using Github or referring to any of Google services, as I think these two are not friendly to the Commons. I hope this will evolve to eliminate this initiative's dependency on these companies.
Finally I noticed a lack of consistency in some of the documentation, besides the .tech issue in the curl docs -- for example, I stumbled upon the link to the v1 index by chance and was unable to get back to it to verify that my node profile was actually updated (the curl command requesting the node still displays "posted", which means: successful, so the index should now count 6 nodes.)

Also I'd like to draw your attention to this conversation on the SocialHub where ActivityPub developers discuss Murmurations, especially the following concern from this message, that the Murmurations Protocol does not use embedding JSON-LD in HTML documents that Pukkamustard mentions as the standard way used by Google to capture data from websites. Maybe an avenue to explore...

To conclude, I like the way the protocol evolved, in line with my early comments comparing the IN COMMON approach, except for a couple of points: first, the linked message does not match our latest iteration (in progress towards RDF graph), but still the tagline and mission were merged into a single description field from which what IN COMMON calls a summary is extracted... With IN COMMON, what was then a tagline and is now a 160-character excerpt from description is called summary, while the description is a longer string that MAY be interpreted as Markdown. The rationale for keeping those fields split is that it alleviates users from having to craft a unique description in a way that machines will parse and do so sub-optimally. It's much easier for people to fathom a "summary" that matches a short description, and another (longer) "description" where they can add details.

I like the fact url became urls -- in the message above I mentioned Resource.homepage_url, but it actually matches a "primary" link from an array. Ditto for the move from logo to an array of images, which could as well evolve into attachments with a media type in case people want to put audio alternates for blind people -- this complication I left aside considering a Markdown description, but it has other issues, like potential security flaws...

All right, this post starts covering way more than just the topic's title, so I will stop here, in the hope this brings food for thought.

edit: Maybe the \n\n in the description is causing an issue?