A small tool to view real-world ActivityPub objects as JSON! Enter a URL
or username from Mastodon or a similar service below, and we'll send a
request with
the right
Accept
header
to the server to view the underlying object.
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"ostatus": "http://ostatus.org#",
"atomUri": "ostatus:atomUri",
"inReplyToAtomUri": "ostatus:inReplyToAtomUri",
"conversation": "ostatus:conversation",
"sensitive": "as:sensitive",
"toot": "http://joinmastodon.org/ns#",
"votersCount": "toot:votersCount",
"Hashtag": "as:Hashtag"
}
],
"id": "https://social.uggs.io/users/chris/statuses/113973373263742475",
"type": "Note",
"summary": null,
"inReplyTo": null,
"published": "2025-02-09T10:07:41Z",
"url": "https://social.uggs.io/@chris/113973373263742475",
"attributedTo": "https://social.uggs.io/users/chris",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://social.uggs.io/users/chris/followers"
],
"sensitive": false,
"atomUri": "https://social.uggs.io/users/chris/statuses/113973373263742475",
"inReplyToAtomUri": null,
"conversation": "tag:social.uggs.io,2025-02-09:objectId=13366517:objectType=Conversation",
"content": "<p>🚨 Fixing the PKI Mess: CAA + Your Own CA via DNS 🚨 </p><p>Right now, any CA can issue a certificate for your domain. Even if you set a CAA record (`issue "letsencrypt.org"`), it only controls *who* can issue, not what cert is valid. This is broken. </p><p>🔐 What if we could fix this using DNS? </p><p><a href=\"https://social.uggs.io/tags/Introducing\" class=\"mention hashtag\" rel=\"tag\">#<span>Introducing</span></a> CAA+CA Fingerprint: Self-Sovereign Certificate Authority<br />Instead of just saying *which CA can issue*, you publish your own CA's fingerprint in DNS. If your CA issues a cert for `awesomecars.com`, browsers should validate it against the DNS-published CA key. </p><p>🔥 How It Works<br />You run your own CA (because why trust the cartel?). You then publish: <br />1️⃣ A CAA record specifying your own CA (with a fingerprint! 🔥) <br />2️⃣ A DNS record with your CA’s public key (like DKIM but for TLS!) </p><p>🔹 Example DNS Setup for `awesomecars.com`: <br />```<br />awesomecars.com. IN CAA 0 issue "pki.awesomecars.com; sha256=abcd1234..."<br />pki.awesomecars.com. IN CERT 6 0 0 (--BEGIN CERTIFICATE-- ....)<br />```<br />Now, only certs signed by your CA are valid for `awesomecars.com`, even if another CA is tricked into issuing a rogue cert. No more CA hijacking! </p><p>🚀 Why Is This Better Than the Current CA Model?<br />✅ Self-Sovereign Identity: If you own the domain, you should own its PKI. <br />✅ Prevents Rogue Certs: No government or rogue CA can fake a cert for your domain. <br />✅ Works Like DKIM for Email: Your CA’s public key is stored in DNSSEC-protected records, just like DKIM keys for email signing. <br />✅ No More External Trust Issues: You control your CA entirely, instead of relying on Google’s CA store. <br />✅ Perfect for Self-Hosting & Internal Networks: No need for external CA trust—your DNS is your trust model. </p><p>🔥 Why Isn’t This a Thing Already?<br />Big Tech hates this idea because it removes their control: <br />❌ Google wants Certificate Transparency (CT), where they control which certs are logged. <br />❌ Commercial CAs make $$$ selling certs. This kills their business. <br />❌ DNSSEC adoption is intentionally kept low by the same companies who don’t want this to succeed. </p><p>Browsers refuse to support TLSA for the same reason—they want centralized CA trust, not self-hosted PKI. </p><p>🔗 Who Needs to Implement This?<br />🚀 Self-hosters & Homelabs: Use this for your own infrastructure. <br />🚀 Email providers: Stop relying on public CAs! <br />🚀 Privacy-focused projects (Tor, Matrix, XMPP, Fediverse, etc.): A true decentralized PKI alternative. <br />🚀 Fediverse devs: Let’s push for DNS-based CA validation! </p><p>What do you think? Would you trust your own CA in DNS over some random commercial CA? </p><p>🔁 Boost this if you want a decentralized PKI revolution! </p><p>🔥 This keeps the focus on self-hosting your own CA, highlights the security flaws of current PKI, and calls out Big Tech’s resistance to decentralized trust. </p><p><a href=\"https://social.uggs.io/tags/PKI\" class=\"mention hashtag\" rel=\"tag\">#<span>PKI</span></a> <a href=\"https://social.uggs.io/tags/Security\" class=\"mention hashtag\" rel=\"tag\">#<span>Security</span></a> <a href=\"https://social.uggs.io/tags/DNSSEC\" class=\"mention hashtag\" rel=\"tag\">#<span>DNSSEC</span></a> <a href=\"https://social.uggs.io/tags/DANE\" class=\"mention hashtag\" rel=\"tag\">#<span>DANE</span></a> <a href=\"https://social.uggs.io/tags/TLSA\" class=\"mention hashtag\" rel=\"tag\">#<span>TLSA</span></a> <a href=\"https://social.uggs.io/tags/CAA\" class=\"mention hashtag\" rel=\"tag\">#<span>CAA</span></a> <a href=\"https://social.uggs.io/tags/SelfHosting\" class=\"mention hashtag\" rel=\"tag\">#<span>SelfHosting</span></a> <a href=\"https://social.uggs.io/tags/Fediverse\" class=\"mention hashtag\" rel=\"tag\">#<span>Fediverse</span></a> <a href=\"https://social.uggs.io/tags/Privacy\" class=\"mention hashtag\" rel=\"tag\">#<span>Privacy</span></a> <a href=\"https://social.uggs.io/tags/Decentralization\" class=\"mention hashtag\" rel=\"tag\">#<span>Decentralization</span></a> <a href=\"https://social.uggs.io/tags/dns\" class=\"mention hashtag\" rel=\"tag\">#<span>dns</span></a> <a href=\"https://social.uggs.io/tags/linux\" class=\"mention hashtag\" rel=\"tag\">#<span>linux</span></a></p>",
"contentMap": {
"en": "<p>🚨 Fixing the PKI Mess: CAA + Your Own CA via DNS 🚨 </p><p>Right now, any CA can issue a certificate for your domain. Even if you set a CAA record (`issue "letsencrypt.org"`), it only controls *who* can issue, not what cert is valid. This is broken. </p><p>🔐 What if we could fix this using DNS? </p><p><a href=\"https://social.uggs.io/tags/Introducing\" class=\"mention hashtag\" rel=\"tag\">#<span>Introducing</span></a> CAA+CA Fingerprint: Self-Sovereign Certificate Authority<br />Instead of just saying *which CA can issue*, you publish your own CA's fingerprint in DNS. If your CA issues a cert for `awesomecars.com`, browsers should validate it against the DNS-published CA key. </p><p>🔥 How It Works<br />You run your own CA (because why trust the cartel?). You then publish: <br />1️⃣ A CAA record specifying your own CA (with a fingerprint! 🔥) <br />2️⃣ A DNS record with your CA’s public key (like DKIM but for TLS!) </p><p>🔹 Example DNS Setup for `awesomecars.com`: <br />```<br />awesomecars.com. IN CAA 0 issue "pki.awesomecars.com; sha256=abcd1234..."<br />pki.awesomecars.com. IN CERT 6 0 0 (--BEGIN CERTIFICATE-- ....)<br />```<br />Now, only certs signed by your CA are valid for `awesomecars.com`, even if another CA is tricked into issuing a rogue cert. No more CA hijacking! </p><p>🚀 Why Is This Better Than the Current CA Model?<br />✅ Self-Sovereign Identity: If you own the domain, you should own its PKI. <br />✅ Prevents Rogue Certs: No government or rogue CA can fake a cert for your domain. <br />✅ Works Like DKIM for Email: Your CA’s public key is stored in DNSSEC-protected records, just like DKIM keys for email signing. <br />✅ No More External Trust Issues: You control your CA entirely, instead of relying on Google’s CA store. <br />✅ Perfect for Self-Hosting & Internal Networks: No need for external CA trust—your DNS is your trust model. </p><p>🔥 Why Isn’t This a Thing Already?<br />Big Tech hates this idea because it removes their control: <br />❌ Google wants Certificate Transparency (CT), where they control which certs are logged. <br />❌ Commercial CAs make $$$ selling certs. This kills their business. <br />❌ DNSSEC adoption is intentionally kept low by the same companies who don’t want this to succeed. </p><p>Browsers refuse to support TLSA for the same reason—they want centralized CA trust, not self-hosted PKI. </p><p>🔗 Who Needs to Implement This?<br />🚀 Self-hosters & Homelabs: Use this for your own infrastructure. <br />🚀 Email providers: Stop relying on public CAs! <br />🚀 Privacy-focused projects (Tor, Matrix, XMPP, Fediverse, etc.): A true decentralized PKI alternative. <br />🚀 Fediverse devs: Let’s push for DNS-based CA validation! </p><p>What do you think? Would you trust your own CA in DNS over some random commercial CA? </p><p>🔁 Boost this if you want a decentralized PKI revolution! </p><p>🔥 This keeps the focus on self-hosting your own CA, highlights the security flaws of current PKI, and calls out Big Tech’s resistance to decentralized trust. </p><p><a href=\"https://social.uggs.io/tags/PKI\" class=\"mention hashtag\" rel=\"tag\">#<span>PKI</span></a> <a href=\"https://social.uggs.io/tags/Security\" class=\"mention hashtag\" rel=\"tag\">#<span>Security</span></a> <a href=\"https://social.uggs.io/tags/DNSSEC\" class=\"mention hashtag\" rel=\"tag\">#<span>DNSSEC</span></a> <a href=\"https://social.uggs.io/tags/DANE\" class=\"mention hashtag\" rel=\"tag\">#<span>DANE</span></a> <a href=\"https://social.uggs.io/tags/TLSA\" class=\"mention hashtag\" rel=\"tag\">#<span>TLSA</span></a> <a href=\"https://social.uggs.io/tags/CAA\" class=\"mention hashtag\" rel=\"tag\">#<span>CAA</span></a> <a href=\"https://social.uggs.io/tags/SelfHosting\" class=\"mention hashtag\" rel=\"tag\">#<span>SelfHosting</span></a> <a href=\"https://social.uggs.io/tags/Fediverse\" class=\"mention hashtag\" rel=\"tag\">#<span>Fediverse</span></a> <a href=\"https://social.uggs.io/tags/Privacy\" class=\"mention hashtag\" rel=\"tag\">#<span>Privacy</span></a> <a href=\"https://social.uggs.io/tags/Decentralization\" class=\"mention hashtag\" rel=\"tag\">#<span>Decentralization</span></a> <a href=\"https://social.uggs.io/tags/dns\" class=\"mention hashtag\" rel=\"tag\">#<span>dns</span></a> <a href=\"https://social.uggs.io/tags/linux\" class=\"mention hashtag\" rel=\"tag\">#<span>linux</span></a></p>"
},
"attachment": [],
"tag": [
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/introducing",
"name": "#introducing"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/pki",
"name": "#pki"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/security",
"name": "#security"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/dnssec",
"name": "#dnssec"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/dane",
"name": "#dane"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/tlsa",
"name": "#tlsa"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/caa",
"name": "#caa"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/selfhosting",
"name": "#selfhosting"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/fediverse",
"name": "#fediverse"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/privacy",
"name": "#privacy"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/decentralization",
"name": "#decentralization"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/dns",
"name": "#dns"
},
{
"type": "Hashtag",
"href": "https://social.uggs.io/tags/linux",
"name": "#linux"
}
],
"replies": {
"id": "https://social.uggs.io/users/chris/statuses/113973373263742475/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://social.uggs.io/users/chris/statuses/113973373263742475/replies?only_other_accounts=true&page=true",
"partOf": "https://social.uggs.io/users/chris/statuses/113973373263742475/replies",
"items": []
}
},
"likes": {
"id": "https://social.uggs.io/users/chris/statuses/113973373263742475/likes",
"type": "Collection",
"totalItems": 11
},
"shares": {
"id": "https://social.uggs.io/users/chris/statuses/113973373263742475/shares",
"type": "Collection",
"totalItems": 13
}
}