diff --git a/docs/src/name-service.md b/docs/src/name-service.md
index 8e223dcf47b..b1767362a51 100644
--- a/docs/src/name-service.md
+++ b/docs/src/name-service.md
@@ -2,16 +2,16 @@
 title: Name Service
 ---
 
-A SPL program for issuing and managing ownership of: domain names, Solana Pubkeys, URLs, Twitter handles, ipfs cid's etc..
+A SPL program for issuing and managing ownership of: domain names, Solana Pubkeys, URLs, Twitter / X handles, IPFS cid's etc..
 
-This program could be used for dns, pubkey etc lookups via a browser extension
+This program could be used for DNS, pubkey etc lookups via a browser extension
 for example, the goal is to create an easy way to identify Solana public keys
 with various links.
 
 Broader use cases are also imaginable.
 
 Key points:
-- A Name is a string that maps to a record (program derived account) which can hold data.
+- A Name is a string that maps to a record (Program Derived Account) which can hold data.
 - Each name is of a certain class and has a certain owner, both are identified
   by their pubkeys. The class of a name needs to sign the issuance of it.
 - A name can have a parent name that is identified by the address of its record.
@@ -41,17 +41,22 @@ Although the ownership and class system makes the administration a given class
 centralized, the creation of new classes is permissionless and as a class owner
 any kind of decentralized governance signing program could be used.
 
-- Twitter handles can be added as names of one specific name class. The class
-  authority will therefore hold the right to add a Twitter handle name. This
-  enables the verification of Twitter accounts for example by asking the user to
-  tweet their pubkey or a signed message. A bot that holds the private issuing
+- Twitter / X handles can be added as names of one specific name class. The class
+  authority will therefore hold the right to add a Twitter / X handle name. This
+  enables the verification of Twitter / X accounts for example by asking the user to
+  post their pubkey or a signed message. A bot that holds the private issuing
   authority key can then sign the Create instruction (with a metadata_authority
-  that is the tweeted pubkey) and send it back to the user who will then submit
+  that is the posted pubkey) and send it back to the user who will then submit
   it to the program.
 In this case the class will still be able to control the data of the name registry, and not the user for example.
 
 Therefore, another way of using this program would be to create a name
 (`"verified-twitter-handles"` for example) with the `Pubkey::default()` class
-and with the owner being the authority. That way verified Twitter names could be
+and with the owner being the authority. That way verified Twitter / X names could be
 issued as child names of this parent by the owner, leaving the user as being
-able to modify the data of their Twitter name registry.
+able to modify the data of their Twitter / X name registry.
+
+Examples of current offerings
+
+* [Solana Name Service](https://sns.id)
+* [AllDomains](https://alldomains.id)