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",
"litepub": "http://litepub.social/ns#",
"directMessage": "litepub:directMessage",
"Hashtag": "as:Hashtag"
}
],
"id": "https://infosec.exchange/users/resingm/statuses/111504710160600705",
"type": "Note",
"summary": null,
"inReplyTo": null,
"published": "2023-12-01T10:34:11Z",
"url": "https://infosec.exchange/@resingm/111504710160600705",
"attributedTo": "https://infosec.exchange/users/resingm",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://infosec.exchange/users/resingm/followers"
],
"sensitive": false,
"atomUri": "https://infosec.exchange/users/resingm/statuses/111504710160600705",
"inReplyToAtomUri": null,
"conversation": "tag:infosec.exchange,2023-12-01:objectId=114374883:objectType=Conversation",
"content": "<p>Glad to see that Verisign plans ahead for a <a href=\"https://infosec.exchange/tags/DNSSEC\" class=\"mention hashtag\" rel=\"tag\">#<span>DNSSEC</span></a> algorithm rollover for the <code>com.</code> TLD. The plan is to discard algorithm 8 (RSA/SHA256) and instead deploy algorithm 13 (ECDSA/SHA-256). Great to see that the largest TLD of planet earth moving towards algorithms with smaller key sizes.</p><p>I checked my <a href=\"https://infosec.exchange/tags/pdns\" class=\"mention hashtag\" rel=\"tag\">#<span>pdns</span></a> database of my public resolvers. To give a comparison for the size reduction (and the reduction of DNS R/A potential):</p><p><code>com.</code>, signed with algorithm 8 returned close to 936 bytes of data.<br><code>nl.</code>, signed with algorithm 13 returns 289 bytes of data.</p><p>This is a reduction of ~70% of the response sizes for DNSSEC validation.</p><p>The rollover is to be expected on or around December 07. More on it in their <a href=\"https://blog.verisign.com/security/dnssec-algorithm-update/\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">blog</a>.</p><p><a href=\"https://infosec.exchange/tags/dns\" class=\"mention hashtag\" rel=\"tag\">#<span>dns</span></a> <a href=\"https://infosec.exchange/tags/tld\" class=\"mention hashtag\" rel=\"tag\">#<span>tld</span></a> <a href=\"https://infosec.exchange/tags/ddos\" class=\"mention hashtag\" rel=\"tag\">#<span>ddos</span></a></p>",
"contentMap": {
"en": "<p>Glad to see that Verisign plans ahead for a <a href=\"https://infosec.exchange/tags/DNSSEC\" class=\"mention hashtag\" rel=\"tag\">#<span>DNSSEC</span></a> algorithm rollover for the <code>com.</code> TLD. The plan is to discard algorithm 8 (RSA/SHA256) and instead deploy algorithm 13 (ECDSA/SHA-256). Great to see that the largest TLD of planet earth moving towards algorithms with smaller key sizes.</p><p>I checked my <a href=\"https://infosec.exchange/tags/pdns\" class=\"mention hashtag\" rel=\"tag\">#<span>pdns</span></a> database of my public resolvers. To give a comparison for the size reduction (and the reduction of DNS R/A potential):</p><p><code>com.</code>, signed with algorithm 8 returned close to 936 bytes of data.<br><code>nl.</code>, signed with algorithm 13 returns 289 bytes of data.</p><p>This is a reduction of ~70% of the response sizes for DNSSEC validation.</p><p>The rollover is to be expected on or around December 07. More on it in their <a href=\"https://blog.verisign.com/security/dnssec-algorithm-update/\" target=\"_blank\" rel=\"nofollow noopener noreferrer\">blog</a>.</p><p><a href=\"https://infosec.exchange/tags/dns\" class=\"mention hashtag\" rel=\"tag\">#<span>dns</span></a> <a href=\"https://infosec.exchange/tags/tld\" class=\"mention hashtag\" rel=\"tag\">#<span>tld</span></a> <a href=\"https://infosec.exchange/tags/ddos\" class=\"mention hashtag\" rel=\"tag\">#<span>ddos</span></a></p>"
},
"attachment": [],
"tag": [
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/dnssec",
"name": "#dnssec"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/pdns",
"name": "#pdns"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/dns",
"name": "#dns"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/tld",
"name": "#tld"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/ddos",
"name": "#ddos"
}
],
"replies": {
"id": "https://infosec.exchange/users/resingm/statuses/111504710160600705/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://infosec.exchange/users/resingm/statuses/111504710160600705/replies?only_other_accounts=true&page=true",
"partOf": "https://infosec.exchange/users/resingm/statuses/111504710160600705/replies",
"items": []
}
},
"likes": {
"id": "https://infosec.exchange/users/resingm/statuses/111504710160600705/likes",
"type": "Collection",
"totalItems": 1
},
"shares": {
"id": "https://infosec.exchange/users/resingm/statuses/111504710160600705/shares",
"type": "Collection",
"totalItems": 0
}
}