So, I wrote the first thing for Balormo's backend tonight. I wanted to do dice rolls, or really RNG (random number generation) broadly, and in this case I wrote the simplest form of it in the TTRPG space: rolling XdY, take the sum.
I did not write an FE for this yet. That's because I want to discuss the way I designed it. Now would be the time to refactor things or change around how it's structured. This is backend proof of concept phase.
For the time being, you can use curl to try it out once you have an account on dev.iddqd.social:
curl -X POST "https://dev.iddqd.social/api/v1/statuses" \ -H "Authorization: Bearer REDACTED" \ -H "Content-Type: multipart/form-data" \ -F "status=Rolling CON for AD&D 2e style" \ -F "source=Pleroma FE" \ -F "visibility=public" \ -F "content_type=text/plain" \ -F "balormo[rng][system]=dice_sum" \ -F "balormo[rng][denomination]=6" \ -F "balormo[rng][quantity]=3"You can find my commit for it here: https://gitgud.io/thestranjer/balormo/-/commit/483800ea9c2e5f913ecc5f1523625c9ad535917d
Unfortunately, Soapbox and Pleroma seem to drop the balormo object in federation. However, quite fortunately, it delivers the Object URL, which does retain that information:
{ "@context": [ "https://www.w3.org/ns/activitystreams", "https://dev.iddqd.social/schemas/litepub-0.1.jsonld", {"@language": "und"} ], "actor": "https://dev.iddqd.social/users/NEETzsche", "attachment": [], "attributedTo": "https://dev.iddqd.social/users/NEETzsche", "balormo": { "rng": { "denomination": 6, "quantity": 3, "results": [1,1,6], "sum": 8, "system": "dice_sum" } }, "cc": ["https://dev.iddqd.social/users/NEETzsche/followers"], "content": "Rolling CON for AD&D 2e style<br/><i>Rolling 3d6, taking the sum.</i><br/><b>Results:</b> 1, 1, 6<br/><b>Sum:</b> 8", "context": "https://dev.iddqd.social/contexts/c2ceeca0-5369-41b9-8be7-2d0a647a7907", "conversation": "https://dev.iddqd.social/contexts/c2ceeca0-5369-41b9-8be7-2d0a647a7907", "id": "https://dev.iddqd.social/objects/48f97fc0-5a63-406f-8822-3ea4493713d9", "published": "2024-05-10T09:13:21.883623Z", "sensitive": null, "source": { "content": "Rolling CON for AD&D 2e style", "mediaType": "text/plain" }, "summary": "", "tag": [],"to": ["https://www.w3.org/ns/activitystreams#Public"], "type": "Note" }The way I wrote this is you just add more fields to the /api/v1/statuses endpoint and give it extra fields. In this case, the system field can be changed and the pattern matching will pick up on the right one and then generate dice rolls etc in the right fashion. For example, I might write a Shadowrun dice roller that rolls d6s given only a pool value and re-rolls 6s until you don't get anymore.
The reason to bake this into the protocol is so that you can manage the data better and change the way it's displayed in the future. The appended roll text to the status will be put in a <div> with a class on it that's invisible for the FE.
Thoughts on how to improve this before I move on to the FE?
@sun @p @jeffcliff @rees @crunklord420 @caekislove @mint @LukeAlmighty @lain
Das Fediverse tut sich schwer, das volle Potential der verschiedenen Activity-Objects auszunutzen, hauptsächlich aus Angst, sie falsch oder schlecht darzustellen und deshalb teilen die meisten großen Netzwerke leider nur Notes.
Dabei könnte es so einfach sein!
@deadsuperhero schreibt auf seinem Blog, dass er eigentlich gerne Articles veröffentlichen will, aber (hauptsächlich) durch Mastodon zu Note gezwungen wird, wenn er sicher gehen will, dass der Text vollständig dargestellt wird.
Here’s the problem, though: the biggest player in the space, Mastodon, does a poor job of supporting Article. Instead, every post Mastodon uses is instead a Note. From a semantic point of view, it might not seem like there’s a lot of difference between the two: both are effectively texts posts that can contain some formatting markup, both can hold an arbitrary amount of characters, and both can effectively be used to represent a full article.
A Content-Fallback Mechanism for the Fediverse
Ironischerweise zeigt Mastodon eine föderierte Note vollständig an, auch wenn der Text weit über die eigentlich erlaubten 500 Zeichen hinaus geht, bei einem Article wird statt dessen aber nur die kurze summary benutzt.
Seine Idee: Ein Content-Fallback Mechanismus!
Das heißt jede Aktivität, egal von welchem Typ, liefert zusätzlich zu dem spezifischen Objekt, eine standardisierte Note (content-fallback):
{ "@context":[ "https://www.w3.org/ns/activitystreams", { "Hashtag":"as:Hashtag" } ], "id":"https://wedistribute.org/2024/04/iftas-dsa-guide/", "type":"Article", "content-fallback": { "content":"IFTAS, the dedicated Trust & Safety organization ...", "mediaType":"text/plain", "summary":"", "tag":[{ "href":"https://wedistribute.org/tags/fediverse", "name":"#fediverse", "type":"Hashtag" }], "type":"Note", "updated":"2024-04-11T20:55:29Z" }}Code-Sprache: JSON / JSON mit Kommentaren (json)Ich verstehe das Problem und finde die Idee generell nicht schlecht, aber eigentlich bietet ActivityPub alles Nötige schon von Haus aus! ActivityPub oder besser ActivityStreams ist so aufgebaut, dass alle Objekte von einem Art Base-Object abgeleitet werden. Das heißt Article, Note, Event oder Place, haben ein gleiches Minimal-Set an Attributen:
Und auch wenn beispielsweise Place oder Event einige spezifische Eigenschaften haben, die nicht jede Plattform „kennt“ und „versteht“, sollte es immer möglich sein, die Beschreibung (description oder summary) und den Titel (name) anzuzeigen.
Das Prinzip ist ähnlich wie, wenn nicht sogar inspiriert durch, schema.org/Thing. Auch hier basieren alle Objekte letztendlich auf einem Thing und trotz der wesentlich größeren Anzahl1 an Objekten und Attributen, können Suchmaschinen sich immer sicher sein, dass es zumindest einen name, eine description und eine url zum Anzeigen gibt.
Bevor wir über also über ein `content-fallback` nachdenken, sollten wir (meiner Meinung nach) erst einmal dafür sorgen, dass die vorhanden Möglichkeiten richtig genutzt werden.
@benpate @trwnh A conflict may arise if other developers will start using same IRIs for something different. So I think FEP namespace is preferable, but you can indicate in the proposal that you want to switch to w3.org/ns/activitystreams namespace later.
@tallship@public.mitra.social @darnell @mattwiebe @tallship@socialhome.network @darnelltv @mattwiebe thanks for your help with debugging the issue!
It was a problem with our infrastructure and the `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` Accept header, not with the plugin itself.
So @silverpill had the right nose!
The problem should be solved now!
@pfefferle @tallship @darnell @tallship Yes, but they are not required for federating with us. The inbox endpoint returns 406 Not Acceptable, so I think there's a problem with Content-Type header
Mitra adds Content-Type: application/ld+json; profile="https://www.w3.org/ns/activitystreams", this what ActivityPub spec requires:
https://www.w3.org/TR/activitypub/#server-to-server-interactions
Maybe @darnell expects a different content type.
@dushman @phnt No you fucking don't.
$ curl -H "Accept: application/activity+json" https://den.raccoon.quest/notes/9qjchkug1e {"@context":["https://www.w3.org/ns/activitystreams",[...]GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.