>Incidentally, after I lived with the Pleroma-scrobble thing for a little bit, I think it's fun but maybe better if there was a link between a "Create"->"Note" and the "Audio" instead of just leaving them flat in the stream, so someone views a thread and instead of a participant's head having whatever they last put into the stream next to it, it's the song they were listening to when the activity was published. This probably sounds like the benefit is dubious for the added complication of figuring out how to cram "the last Audio activity with a created_at>=CURRENT_TIMESTAMP-duration" into the activity, but please humor me for a moment because I think it enables a handful of very cool things.
I like this idea. Picking the right one could be difficult though, assuming the length field is left blank. How does one determine which song they were listening to when the post was made without that? I suppose you could make an assumption of 5min when it's left blank, but implementation for this idea gets murkier without clear data. I'll definitely sleep on it, though.
>I wonder if multiple links might be doable. I mean, after I noticed there was an associated link when I looked at it on iddqd.social, the first thing I wanted to do was turn it into a stream of pirated music by shoving the songs into Revolver or IPFS on play and then using the audio as the URL
You can do that and I think it's valid. What you put in the url field is Not My Problem. You could fucking Rick Roll me with it and I'd be fine with that. If you direct it to an .exe file, Windows normies will just have to learn to not run random executables. I'm taking this position because I can't imagine non-sequitur scrobbles being anything worse than memes and pranks. But if you can think of something worse than that, by all means, tell me.
>I wonder if multiple links might be doable.
Multiple links is possible by ActivityPub's standard but I didn't put that in my edit of Pleroma API. That could change, of course.
>I mean, after I noticed there was an associated link when I looked at it on iddqd.social, the first thing I wanted to do was turn it into a stream of pirated music by shoving the songs into Revolver or IPFS on play and then using the audio as the URL
I think you're driving at a liability concern here and I'm sensitive to that, now that I think on it. I'm not sure I care, though, because linking to a YouTube video of a "pirated" song vs linking to an MP3 should be basically the same. Maybe I'm being naive, but we'll see.
>Even cooler would be if, given that some of those links are to services that are embeddable and that there's also the possibility of directly linking to the audio, you could have a "play" button with a quasi-intelligent embed widget, <audio> for everything that wasn't recognized and then regular "official" embed for the sites that are recognized by the widget code (or just some yt-dlp-powered media proxy).
I like this idea but I also don't want to go through the trouble of implementing it.
>Bunch of stuff about making Audio "scrobbles" timeline-visible
I like most of this and am sympathetic to it, but for me the reason not to is primarily social, not technical. That is, getting FOSS spergs to accept PRs is nearly impossible. I literally had to have this fucking committee tribunal to get hj to merge url into PleromaBE, and he expected me to change it to externalLink for reasons. It really sucked. I get that I can be an abrasive person sometimes, but there's little point in doing all this technical work to get jammed up in what amounts to a bureaucratic approval process. This legitimately has made me reluctant to contribute.
All that said, I have considered forking PleromaFE and BE (and calling that fork "Balormo", lol), just so I can stuff it with experimental ActivityPub actions. My understanding of the way Pleroma is designed to handle "wacky" types of activities and shapes is to just fall back on the content field, which means you can submit structured data in any form you want and then just generate a bit of HTML in the content field. The advantage to this method is that with a well-designed FE/BE, you can update the way old messages are displayed after the fact whereas with reliance on the content field that becomes much harder (I'm not writing a regex to update all that old shit, sorry).
But really, being able to emit messages of various forms in a structured fashion would improve fedi immensely. Here are some ideas that I came up with with things that you could do this with (these are all off-the-cuff and naturally should face more design scrutiny before evaluating them):
I could go on for hours listing stuff, but I think the benefits of structuring this kind of information, even if federated, is valuable. I'd love to be able to have this information stored and federated in a structured fashion so that I and others can fiddle with the presentation in perpetuity and on an individual basis without having to change any of the actual content, which federates quietly in the background.
I'll sleep on this Balormo idea more, but I have other projects, like my zine, to work on, and that sucks up a surprising amount of time.
Literally, just shoot for true randomness, or as close to it as you’re going to get. I don’t think there’s a better entropy system out there than random.org‘s ambient radio noise seeding so just use that.
True randomness. Use random.org‘s API and base your RNG on ambient radio noise.
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.