Member Avatar for EddieC
EddieC 0 Posting Whiz in Training

MySpace Tuesday announced some changes to its developer program, fine-tuning its policies about the way member applications are allowed to communicate with users. It also leaked news of enhancements to its messaging API set to be available in June.

The were outlined in a blog post by the MySpace Developer Team. In essence, they’re looking to curb spam and other forms of unsolicited invitations and enticements.

Here’s the essence of what’s new in the :


• No incentives may be given to a member for sending a message, bulletin, comment, or any other form of communication. This includes “points,” “bucks,” increased standing, or even features within the app.
• It must be very clear to a member what they are sending, when they are sending communication. “Share with friends” is not sufficient messaging, the link must state “send comment,” “send bulletin,” and so on.
• The “no popups” rule we have had in place since day one applies to messaging windows. This means no more popping up a messaging window the first time someone tries to use an app. No popping up messaging windows without a user clicking on a very clearly marked link.


The new rules go into effect immediately for all applications developed after today. For those already deployed, developers have until June 3, at 8:00 pm ET to get their apps into compliance. “After that date we will review all applications and take action on those that are not in compliance with the new guidelines,” read the post. MySpace set up a about the new rules.

The company in June will add an Applications Communication Channel to its messaging API, describing it as a “brand-new messaging service built specifically for apps that will enable custom app invited and notifications.”

  • 1 Contributor
  • 0 Replies
  • 215 Views

Dani AI

Generated

covered the announcement succinctly. The checklist below focuses on concrete engineering, QA, and operational steps that bring an app into compliance quickly and reduce future rework when the platform updates its messaging surface.

Start with a targeted audit: search your codebase for any client or server paths that trigger messages, pop windows, or grant rewards tied to invites. Make a short inventory (file, function, trigger, intended user action) and prioritize fixes by how easy they are to exploit or cause accidental sends. Replace ambiguous UI copy with clear action verbs and require an explicit user action to open any messaging UI.

Keep the send decision client-driven but the send operation server-side. Show a preview and require an affirmative confirmation before calling your backend. Example pattern:

<button id="sendItem" aria-label="Send message to selected friends">Send message</button>

<script>
document.getElementById('sendItem').addEventListener('click', async function () {
  if (!confirm('Send this message to the selected recipients?')) return;
  await fetch('/app/send-message', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({ ids: selectedIds, text: messageText })
  });
});
</script>

Operational safeguards: queue outgoing messages, enforce per-user and per-app rate limits, make sends idempotent, and log the exact preview plus a consent timestamp for each send (useful if the platform audits apps). Add automated UI tests that assert no unsolicited messaging flows and integration tests for the server endpoint. Architect your code with a single messaging interface so you can plug in the platform’s new messaging endpoint with minimal changes. Finally, update in-app help and privacy text to reflect how invites and notifications work and keep a short rollback plan in case enforcement hits before you finish.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.