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"
}
],
"id": "https://infosec.exchange/users/tomrittervg/collections/featured",
"type": "OrderedCollection",
"totalItems": 1,
"orderedItems": [
{
"id": "https://infosec.exchange/users/tomrittervg/statuses/113443377970323498",
"type": "Note",
"summary": null,
"inReplyTo": "https://infosec.exchange/users/swapgs/statuses/113442993152436812",
"published": "2024-11-07T19:42:54Z",
"url": "https://infosec.exchange/@tomrittervg/113443377970323498",
"attributedTo": "https://infosec.exchange/users/tomrittervg",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://infosec.exchange/users/tomrittervg/followers",
"https://infosec.exchange/users/swapgs"
],
"sensitive": false,
"atomUri": "https://infosec.exchange/users/tomrittervg/statuses/113443377970323498",
"inReplyToAtomUri": "https://infosec.exchange/users/swapgs/statuses/113442993152436812",
"conversation": "tag:infosec.exchange,2024-11-07:objectId=210748679:objectType=Conversation",
"content": "<p><span class=\"h-card\" translate=\"no\"><a href=\"https://infosec.exchange/@swapgs\" class=\"u-url mention\">@<span>swapgs</span></a></span> Automatically pulling the latest tag is also a bad idea. </p><p>Tracking tags or tip is great so long as it's _not_ merged in automatically and is _not_ run in a CI environment that could extract secrets or otherwise corrupt shared build caches/etc. The purpose of these jobs should be a canary for you to identify regressions (build or perf) immediately so you know _which_ upstream commit caused it. You can send that to upstream to keep the feedback cycle of build->test->review->ship->debug->fix as tight as possible while the change is forefront of _their_ mind. </p><p>But for the code you actually _ship_ you should be pinning your dependencies to specific versions/tags. Bumping those versions/tags requires an actual code review you are responsible for, a code review to the same standard as the rest of your patches. </p><p>cargo-vet in the rust ecosystem is designed to help you diffuse that effort when your dependency is being reviewed by some other organization (or author) that you trust to the same level as your own developers.</p><p>At least, that's my take on best practice, and what we do at Mozilla.</p>",
"contentMap": {
"en": "<p><span class=\"h-card\" translate=\"no\"><a href=\"https://infosec.exchange/@swapgs\" class=\"u-url mention\">@<span>swapgs</span></a></span> Automatically pulling the latest tag is also a bad idea. </p><p>Tracking tags or tip is great so long as it's _not_ merged in automatically and is _not_ run in a CI environment that could extract secrets or otherwise corrupt shared build caches/etc. The purpose of these jobs should be a canary for you to identify regressions (build or perf) immediately so you know _which_ upstream commit caused it. You can send that to upstream to keep the feedback cycle of build->test->review->ship->debug->fix as tight as possible while the change is forefront of _their_ mind. </p><p>But for the code you actually _ship_ you should be pinning your dependencies to specific versions/tags. Bumping those versions/tags requires an actual code review you are responsible for, a code review to the same standard as the rest of your patches. </p><p>cargo-vet in the rust ecosystem is designed to help you diffuse that effort when your dependency is being reviewed by some other organization (or author) that you trust to the same level as your own developers.</p><p>At least, that's my take on best practice, and what we do at Mozilla.</p>"
},
"attachment": [],
"tag": [
{
"type": "Mention",
"href": "https://infosec.exchange/users/swapgs",
"name": "@swapgs"
}
],
"replies": {
"id": "https://infosec.exchange/users/tomrittervg/statuses/113443377970323498/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://infosec.exchange/users/tomrittervg/statuses/113443377970323498/replies?only_other_accounts=true&page=true",
"partOf": "https://infosec.exchange/users/tomrittervg/statuses/113443377970323498/replies",
"items": []
}
},
"likes": {
"id": "https://infosec.exchange/users/tomrittervg/statuses/113443377970323498/likes",
"type": "Collection",
"totalItems": 2
},
"shares": {
"id": "https://infosec.exchange/users/tomrittervg/statuses/113443377970323498/shares",
"type": "Collection",
"totalItems": 0
}
}
]
}