Users can register offensive and unwanted UGC creators to the blocked-user list. Only one blocked-user list is saved per Nintendo 3DS system. The list can hold up to 1,000 UGC creators.
Unless instructed otherwise, support for the blocked-user list is optional. If your application supports the blocked-user list, your application must comply with the guidelines in this chapter.
The UGC creator information registered in the blocked-user list is different from the user information used by CTR-NEX. There are currently no features provided for linking this information together, so the blocked-user list cannot be used as a matchmaking blacklist or for other similar purposes.
7.5.1 Creator Information
You must add the following creator information to any UGC that is subject to the blocked-user list.
-
UGC Creator ID
This ID (also called the UGC author ID) is needed to specifically identify the creator of the UGC and register him or her to the blocked-user list. You can get this ID using the nn::ubl::GetUserId function. -
Creator Name
UGC that is subject to the blocked-user list allows a high degree of expression and has the potential for misuse. The purpose of adding the creator's name to such UGC is to reduce anonymity and discourage misuse of UGC.
You are free to decide what name the application will use as the creator name; for example, it could be the system user name, a Mii nickname, or the name of a character in the application.
If UGC is altered by someone other than the creator and then redistributed, you must overwrite the creator information originally added to the UGC with the information of the user who modified it.
If your application treats multiple instances of UGC that are subject to the blocked-user list as a single piece of data, and always shows them together on the screen, then there is no problem with adding just the information for one creator (UGC creator ID and creator name) to all of the data. For example, if you always show a photo and a 50-character comment together, then you can treat them as a single instance of UGC, and assign common UGC creator information to them. If these two UGC items will be displayed separately, add UGC creator information to each one.
7.5.1.1 Adding Creator Information
Guideline Item |
When the user creates UGC subject to the blocked-user list, the application must add the creator information (UGC creator ID and creator name) to the UGC. If UGC is modified by someone other than the creator and then redistributed, the application must overwrite the creator information added to the UGC with the creator information of the user who modified it. |
---|---|
Software to Be Tested |
Applications that support the blocked-user list. |
Test Method |
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|
7.5.2 Removing UGC
When your application receives new UGC, you must check whether the creator has been registered to the blocked-user list before displaying the UGC. You can use the nn::ubl::IsExist function to check whether the creator has been registered to the blocked-user list. If the creator has been registered to the blocked-user list, you must remove the UGC and not show it to the user. “Removing” UGC means either deleting the UGC automatically, or hiding it so it is not displayed to the user.
However, your application is not required to remove UGC it receives via StreetPass with any application using the SDK 5.x series or later. This is because system versions that support the SDK 5.x series are not capable of performing StreetPass at all with users on the blocked-user list. That said, if the communication partner is using a system version that predates support for the SDK 5.x series, StreetPass will occur even if that partner is registered to the blocked-user list. This means that if your application is capable of StreetPass with any application using the SDK 4.x series or earlier, your application itself is responsible for removing the UGC when necessary.
Strictly speaking, even if your application communicates with applications using the SDK 4.x series or earlier, your application itself is not required to remove the UGC as long as you can guarantee that those other applications are running on system versions that have been updated to support the SDK 5.x series. In the following cases, you would be able to guarantee that a given application is running on a system version that supports the SDK 5.x series.
- The application in question is card-based, and a system update to a system version that supports the SDK 5.x series is built into its Game Card.
- The application in question is a download-only application, and it was released after system versions that support the SDK 5.x series were made available.
In order to purchase an application from Nintendo eShop, the user must update to the latest system version. Therefore, applications that meet this condition are guaranteed to be running on a system version that supports the SDK 5.x series.
If you need help confirming whether other applications that your application communicates with meet the above conditions, contact Nintendo at support@noa.com.
7.5.2.1 Handling Receipt of New UGC
Guideline Item |
When an application receives new UGC that is subject to the blocked-user list, it must check whether the creator of the UGC is on the blocked-user list either upon receiving it or before displaying it, and it must remove the UGC if the sender is on the list. |
---|---|
Software to Be Tested |
Applications that support the blocked-user list. |
Exceptions |
Support for UGC received via StreetPass between applications both using the SDK 5.x series or later. |
Test Method |
|
Pass/Fail Determination |
Passes if in step 7, the UGC received in step 6 is removed and not displayed. |
7.5.3 Sequence for Registering to Blocked-User List
The sequence for registering to the blocked-user list allows users to register offensive UGC creators to the blocked-user list. Thereafter, all UGC from that sender is blocked. If your application uses the blocked-user list you must implement a sequence for registering UGC creators to the blocked-user list.
It is up to the application when to display the sequence for registering to the blocked-user list. It is acceptable to make this sequence available at any time from a menu selection, or to display it when receiving or deleting UGC. It is also acceptable to show users a list of received UGC and let them select offensive UGC from the list, or to ask the user whether to add the UGC creator to the blocked-user list when the user receives or deletes UGC. However, the user must have at least one opportunity to register the creator of UGC to the blocked-user list after the application displays the UGC.
If your application implements a sequence for registering to the blocked-user list, then it must comply with items 1 to 3 below.
- The sequence for registering UGC creators to the blocked-user list must display creator names together with their UGC, and allow the user to register the creators of offensive UGC to the blocked-user list.
- Before registering a UGC creator to the blocked-user list, confirm the action with the user, displaying a message like the following: “Add to blocked-user list?” You are free to reword this message, as long as the meaning does not change.
- If the user confirms the registration of the creator to the blocked-user list, use the nn::ubl::Entry function to take the UGC creator ID added to the UGC and register it to the blocked-user list.
7.5.3.1 Support for Sequence for Registering to Blocked-User List
Guideline Item |
For UGC subject to the blocked-user list, the application must implement a sequence for registering creators of such UGC to the blocked-user list. |
---|---|
Software to Be Tested |
Applications that support the blocked-user list. |
Test Method |
|
Pass/Fail Determination |
Passes if all of the following conditions are met.
|