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",
"blurhash": "toot:blurhash",
"focalPoint": {
"@container": "@list",
"@id": "toot:focalPoint"
},
"Hashtag": "as:Hashtag"
}
],
"id": "https://mathstodon.xyz/users/xameer/statuses/114357271179042399",
"type": "Note",
"summary": null,
"inReplyTo": "https://23.social/users/alios/statuses/114357006256596894",
"published": "2025-04-18T05:17:58Z",
"url": "https://mathstodon.xyz/@xameer/114357271179042399",
"attributedTo": "https://mathstodon.xyz/users/xameer",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://mathstodon.xyz/users/xameer/followers",
"https://23.social/users/alios"
],
"sensitive": true,
"atomUri": "https://mathstodon.xyz/users/xameer/statuses/114357271179042399",
"inReplyToAtomUri": "https://23.social/users/alios/statuses/114357006256596894",
"conversation": "tag:mathstodon.xyz,2025-04-18:objectId=148964177:objectType=Conversation",
"content": "<p><span class=\"h-card\" translate=\"no\"><a href=\"https://23.social/@alios\" class=\"u-url mention\">@<span>alios</span></a></span> <br />GOAL: or Isolated , interoperable env , shells by path, w/ central config cc</p><p>envs need not be interoperaple for different langs , say cc has a "devenv.lib.mkshell" for a rust tool `x` which is a runtime dep of epkgs 'ey`for rust work<br />Now If I enter this devshell with nix `develop ` and do a ` cargo install x` here <br />path of x is <br />> .devenv/state/cargo-install/bin/<br />Do note that my PWD is not ${HOME} here.<br />> But if I do a cargo install x from ${HOME} , it ll be in ~/.cargo/bin<br />Now lets say I install a melpapackages `ey` with my dotfiles' emacs.nix "emacs overlay`<br />It may be<br />`ls ~/.emacs.d/elpa/ | grep ey.elc` iff it's byte-compiled.<br /> ey won't find it `x` , till you explicitly add this emacs load-path or to NIX-BUFFER's default.nix list of deps /project [This is just for the projects of 1 lang , nearly any serious work has > = 2] ,<br />or write .envrc /per project , so no global devenv/devshell. <br />Not every dir need be byte compiled <br />Possible reasons<br />While - <br />1. Nix does follow the XDG specs, Emacs does not fully follow it for its configuration and data files.<br />2. NIx Does not follow FHS hierarchy, Emacs Does.<br />3. Nix build re reproducible.<br />4. Nix is content addressed , store (hashed) paths <br />nix-instantiate --eval-only --expr '(import <nixpkgs> {}).emacs.outPath', it could be emacs or go or cargo or whatever your need, it need not have .<br />Some of your emacs data can be here. But I care bout getting deps in the path</p><p>One possible way could be to write a global devshell just for my init.el and launch it from there. But it's not easily extendable , more langs' projects ll put me back to square one.<br />Just nix-buffer seems to unsustainable <br /><a href=\"https://mathstodon.xyz/tags/nix\" class=\"mention hashtag\" rel=\"tag\">#<span>nix</span></a> <a href=\"https://mathstodon.xyz/tags/emacs\" class=\"mention hashtag\" rel=\"tag\">#<span>emacs</span></a></p>",
"contentMap": {
"en": "<p><span class=\"h-card\" translate=\"no\"><a href=\"https://23.social/@alios\" class=\"u-url mention\">@<span>alios</span></a></span> <br />GOAL: or Isolated , interoperable env , shells by path, w/ central config cc</p><p>envs need not be interoperaple for different langs , say cc has a "devenv.lib.mkshell" for a rust tool `x` which is a runtime dep of epkgs 'ey`for rust work<br />Now If I enter this devshell with nix `develop ` and do a ` cargo install x` here <br />path of x is <br />> .devenv/state/cargo-install/bin/<br />Do note that my PWD is not ${HOME} here.<br />> But if I do a cargo install x from ${HOME} , it ll be in ~/.cargo/bin<br />Now lets say I install a melpapackages `ey` with my dotfiles' emacs.nix "emacs overlay`<br />It may be<br />`ls ~/.emacs.d/elpa/ | grep ey.elc` iff it's byte-compiled.<br /> ey won't find it `x` , till you explicitly add this emacs load-path or to NIX-BUFFER's default.nix list of deps /project [This is just for the projects of 1 lang , nearly any serious work has > = 2] ,<br />or write .envrc /per project , so no global devenv/devshell. <br />Not every dir need be byte compiled <br />Possible reasons<br />While - <br />1. Nix does follow the XDG specs, Emacs does not fully follow it for its configuration and data files.<br />2. NIx Does not follow FHS hierarchy, Emacs Does.<br />3. Nix build re reproducible.<br />4. Nix is content addressed , store (hashed) paths <br />nix-instantiate --eval-only --expr '(import <nixpkgs> {}).emacs.outPath', it could be emacs or go or cargo or whatever your need, it need not have .<br />Some of your emacs data can be here. But I care bout getting deps in the path</p><p>One possible way could be to write a global devshell just for my init.el and launch it from there. But it's not easily extendable , more langs' projects ll put me back to square one.<br />Just nix-buffer seems to unsustainable <br /><a href=\"https://mathstodon.xyz/tags/nix\" class=\"mention hashtag\" rel=\"tag\">#<span>nix</span></a> <a href=\"https://mathstodon.xyz/tags/emacs\" class=\"mention hashtag\" rel=\"tag\">#<span>emacs</span></a></p>"
},
"updated": "2025-04-18T05:59:59Z",
"attachment": [
{
"type": "Document",
"mediaType": "image/png",
"url": "https://media.mathstodon.xyz/media_attachments/files/114/357/313/198/096/479/original/b692cc26a4e98730.png",
"name": null,
"blurhash": "U4R2_G4o%M-;0Kof%LofWBt7RjM|t7Rjj[j[",
"width": 953,
"height": 536
},
{
"type": "Document",
"mediaType": "image/png",
"url": "https://media.mathstodon.xyz/media_attachments/files/114/357/436/291/419/782/original/aece57f05faece8a.png",
"name": null,
"blurhash": "U9R2_G01IVoM%MxaayRkofofj@ay?Hxuaya{",
"width": 1018,
"height": 231
}
],
"tag": [
{
"type": "Mention",
"href": "https://23.social/users/alios",
"name": "@alios@23.social"
},
{
"type": "Hashtag",
"href": "https://mathstodon.xyz/tags/emacs",
"name": "#emacs"
},
{
"type": "Hashtag",
"href": "https://mathstodon.xyz/tags/nix",
"name": "#nix"
}
],
"replies": {
"id": "https://mathstodon.xyz/users/xameer/statuses/114357271179042399/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://mathstodon.xyz/users/xameer/statuses/114357271179042399/replies?min_id=114357803739285081&page=true",
"partOf": "https://mathstodon.xyz/users/xameer/statuses/114357271179042399/replies",
"items": [
"https://mathstodon.xyz/users/xameer/statuses/114357803739285081"
]
}
},
"likes": {
"id": "https://mathstodon.xyz/users/xameer/statuses/114357271179042399/likes",
"type": "Collection",
"totalItems": 0
},
"shares": {
"id": "https://mathstodon.xyz/users/xameer/statuses/114357271179042399/shares",
"type": "Collection",
"totalItems": 0
}
}