Untitled attachment

Notices where this attachment appears

1. Embed this notice
   feld (feld@friedcheese.us)'s status on Thursday, 05-Sep-2024 10:55:44 JST feld

   in reply to
   @i @lain @phnt @romin Dumped the whole raw query with all our search filters etc and discovered it's our filter on public posts that's breaking search for this here.
   
   AND ($1 && a0."recipients")
   
   the $1 it's checking recipients for: {"https://www.w3.org/ns/activitystreams#Public", "https://bikeshed.party/#Public"}
   
   cut that out of the query and I'm getting the match to show!
   
   the recipients being returned from that query when it DOES match because I removed that filter:
   
   {https://fluffytail.org/users/phnt,https://friedcheese.us/users/feld/followers,https://lain.com/users/lain,https://shitposter.world/users/romin,https://
   friedcheese.us/users/feld}
   
   Interesting...
2. Embed this notice
   cow@m.moooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooo's status on Wednesday, 10-Jul-2024 05:45:54 JST cow

   @mint same shit on mitra lol, except it can't even fetch the thread

   Jul 09 20:41:13 mootra mitra[212201]: 2024-07-09T20:41:13 mitra_activitypub::importers [INFO] fetched object https://ryona.agency/objects/1fe7ecba-c779-44be-9365-af9992216676 Jul 09 20:41:16 mootra mitra[212201]: 2024-07-09T20:41:16 mitra::mastodon_api::search::helpers [WARN] error sending request for url (http://[200:fff8:9719:292d:c58e:957d:c3e1:6997]/objects/9377ae0b-1d5e-49df-8122-1787b0d063dd): error trying to connect: tcp connect error: Network is unreachable (os error 101) Jul 09 20:41:16 mootra mitra[212201]: 2024-07-09T20:41:16 mitra_activitypub::importers [INFO] fetched actor https://ryona.agency/objects/1fe7ecba-c779-44be-9365-af9992216676 Jul 09 20:41:16 mootra mitra[212201]: 2024-07-09T20:41:16 mitra::mastodon_api::search::helpers [WARN] invalid actor object Jul 09 20:41:58 mootra mitra[212201]: 2024-07-09T20:41:58 mitra_activitypub::queues [WARN] failed to process activity (error sending request for url (http://[200:fff8:9719:292d:c58e:957d:c3e1:6997]/objects/919fc85b-25b2-4b24-bbfd-e3de365945f7): error trying to connect: tcp connect error: Network is unreachable (os error 101)) (attempt #3): {"@context":["https://www.w3.org/ns/activitystreams","https://ryona.agency/schemas/litepub-0.1.jsonld",{"@language":"und"}],"actor":"https://ryona.agency/users/mint","bto":[],"cc":[],"context":"https://mk.magicka.org/notes/9rs86mzaa9y5012e","id":"https://ryona.agency/activities/ea0b8640-7488-40fe-9b45-f920f8bdc4e6","object":"http://[200:fff8:9719:292d:c58e:957d:c3e1:6997]/objects/919fc85b-25b2-4b24-bbfd-e3de365945f7","published":"2024-07-09T20:21:26.992399Z","to":["http://[200:fff8:9719:292d:c58e:957d:c3e1:6997]/users/flint","https://ryona.agency/users/mint/followers","https://www.w3.org/ns/activitystreams#Public"],"type":"Announce"}
3. Embed this notice
   Nimda (nimda@wizard.casa)'s status on Monday, 08-Jul-2024 18:19:05 JST Nimda

   in reply to

   @silverpill looks like only 107 entries, starting with this one

   Jul 07 13:41:58 wizard.casa mitra[40109]: 2024-07-07T13:41:58 mitra_activitypub::queues [WARN] failed to process activity (error sending request for url (https://detroitriotcity.com/objects/e8f71c97-071b-4aac-b070-9563ec29a357): error trying to connect: tcp connect error: Connection timed out (os error 110)) (attempt #1): {"@context":["https://www.w3.org/ns/activitystreams","https://social.hendrixgames.com/schemas/litepub-0.1.jsonld",{"@language":"und"}],"actor":"https://social.hendrixgames.com/users/thendrix","cc":["https://www.w3.org/ns/activitystreams#Public"],"context":"https://shitposter.world/contexts/065a8481-e0bc-4be3-941e-f263b7a7eee1","directMessage":false,"id":"https://social.hendrixgames.com/activities/60da1d6e-9f5e-481a-8133-87fe9d9f07ca","object":{"actor":"https://social.hendrixgames.com/users/thendrix","attachment":[],"attributedTo":"https://social.hendrixgames.com/users/thendrix","cc":["https://www.w3.org/ns/activitystreams#Public"],"content":"<p>China plays the game best... so not much little people can do when even the elite are captured by them. One of the main reasons the West is deindustiralized now are the new opium wars and the bowed elites cashing in on offshoring everything.</p>","context":"https://shitposter.world/contexts/065a8481-e0bc-4be3-941e-f263b7a7eee1","conversation":"https://shitposter.world/contexts/065a8481-e0bc-4be3-941e-f263b7a7eee1","id":"https://social.hendrixgames.com/objects/c030a4a0-ee41-40a0-82a9-509e66d92164","inReplyTo":"https://shitposter.world/objects/03b6cbed-59b5-4b9e-8827-2193e5c75b9b","published":"2024-07-07T19:21:02.550794Z","sensitive":false,"source":{"content":"China plays the game best... so not much little people can do when even the elite are captured by them. One of the main reasons the West is deindustiralized now are the new opium wars and the bowed elites cashing in on offshoring everything.","mediaType":"text/markdown"},"summary":"","tag":[{"href":"https://detroitriotcity.com/users/ChristiJunior","name":"@ChristiJunior@detroitriotcity.com","type":"Mention"},{"href":"https://shitposter.world/users/augustus","name":"@augustus@shitposter.world","type":"Mention"},{"href":"https://shitposter.world/users/sun","name":"@sun@shitposter.world","type":"Mention"}],"to":["https://shitposter.world/users/sun","https://social.hendrixgames.com/users/thendrix/followers","https://detroitriotcity.com/users/ChristiJunior","https://shitposter.world/users/augustus"],"type":"Note"},"published":"2024-07-07T19:21:02.550688Z","to":["https://shitposter.world/users/sun","https://social.hendrixgames.com/users/thendrix/followers","https://detroitriotcity.com/users/ChristiJunior","https://shitposter.world/users/augustus"],"type":"Create"}
   not sure if that's enough to cause the queue to fill up like that

4. Embed this notice
   NEETzsche (neetzsche@iddqd.social)'s status on Friday, 10-May-2024 18:33:01 JST NEETzsche

   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&amp;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

5. Embed this notice
   Vivi Nella Verita (verita84eva@poster.place)'s status on Saturday, 27-Apr-2024 01:59:09 JST Vivi Nella Verita
   @dj
   
   A function to actually clean Akkoma /Pleroma well
   
   ```
   DATABASES=(akkoma detroitriotcity)
   echo "Stopping Akkoma"
   systemctl stop akkoma
   for i in "${DATABASES[@]}"; do
   echo "Scanning Fderated Posts to Delete: $i"
   su postgres -s /bin/bash -lc "echo \"SELECT COUNT(*) FROM \"objects\" AS o0 WHERE (o0.\"data\"->'to' ? 'https://www.w3.org/ns/activitystreams#Public' OR o0.\"data\"->'cc' ? 'https://www.w3.org/ns/activitystreams#Public') AND (o0.\"inserted_at\" < now() - interval '15 days' ) AND (split_part(o0.\"data\"->>'actor', '/', 3) != '$i')\" | psql $i"
   echo "Deleting Objects for: $i"
   su postgres -s /bin/bash -lc "echo \"DELETE FROM \"objects\" AS o0 WHERE (o0.\"data\"->'to' ? 'https://www.w3.org/ns/activitystreams#Public' OR o0.\"data\"->'cc' ? 'https://www.w3.org/ns/activitystreams#Public') AND (o0.\"inserted_at\" < now() - interval '15 days' ) AND (split_part(o0.\"data\"->>'actor', '/', 3) != '$i')\" | psql $i"
   echo "Deleting Activities for: $i"
   su postgres -s /bin/bash -lc "echo \"DELETE FROM \"activities\" where data->>'type' = 'Create' and local = 'f' and inserted_at < now() - interval '10 days'"\" | psql $i
   echo "Starting Akkoma: $i"
   systemctl start akkoma
   done
   }
   ```
6. Embed this notice
   :p: (p@bae.st)'s status on Wednesday, 03-Apr-2024 14:01:59 JST :p:
   :denton::hacker_f::hacker_s::hacker_e:::captcrunch:
   
   SPC is down! I don't know for how long, and accounts apparently moved to shitposter.world, so I am also at @p, but because I don't know if people know about that server (I didn't know about it until yesterday, and I just stumbled across it on SPC), Imma be on @p for a minute until FSE's bugout zone comes online (the machine is assembled and booting things and prerequisites installed and whatnot; it is a lot of fun to type `make -j64` and really *mean* it, but most of the packages I built before the hardware arrived). I hope to finish the configuration in time to drive the box down there tonight or tomorrow night, although it may take a minute or two for some things.
   
   Once the machine is back online, some pretty easy stuff will be back in a hurry: things like git.fse and blog.fse and bloat and whatnot. As I said a while ago, I will probably set up a bugout zone instance, just keep the users table so FSE refugees can log in with their regular username/password, same version of Balormo and everything, basically minimal-effort bugout zone. I'll be on the bugout zone server, FSE refugees are welcome (registrations will be closed, so you'll only be able to get in if you already had an FSE account when the machine exploded), but it will be unstable because its primary purpose is to help with Revolver development (there are things that would be much easier to do with current, live data coming in) and it will probably usually be slow or weird and I will not be doing normal server things. Some of the slowness will be a result of a bunch of Revolver stuff getting shoved around through the system, so it will be busy, some of the slowness will be because the machine is spec'd to do Revolver-style things rather than Pleroma-style things like the previous machine (e.g., the dead box had a really massive amount of RAM for Postgres, the way resources are partitioned in this machine, there's less RAM available in one place). But it'll be there if you want it and you don't mind being subject to technical whimsy.
   
   The bugout zone will be on a subdomain or maybe I grab a different domain for a minute, I don't know. I'll announce it. There will be something that is up at freespeechextremist.com but will not be quite usable for a while, as it's software under active development, a lot of parts are missing, some things are stubbed, etc. The media needs to move and that'll be trickier than it would have been if the box hadn't died prematurely, but I expect the old stuff will be able to come back; the newer uploads (and whatever stuff was fetched on demand after the media server moved to Revolver in December) should be exactly where it was, so it'll be visible again when the media.fse redirect is back in place.
   
   The Postgres/Pleroma to Revolver ingestor's slowness is because I've been using a dumb on-disk storage scheme (and partly because while I'm debugging it, it crashes and dumps the failed data instead of continuing and then storing the rejects somewhere, and everything stopping and waiting for me to fix a bug hampers throughput); I was wondering how long I could get away with that storage mechanism, and the answer is "until about now". So far, all of the rejected data comes from in-development software with bugs that were fixed years ago, so data coming out of the big three servers (Pleroma, Mastodon, Misskey) should all be handled correctly. Once an entity is ingested, it's got a normalized representation, but for the sake of the /objects/ proxy feature, currently what we keep around is the original representation, so that what gets returned is exactly what the server reported. This is less than ideal. The current indexing method is really simple and really fast (under 20ms for timelines: TWKN, tags, profiles, etc.) but there's a lot of disk overhead so it needs to be reworked, and part of that might be done by reworking the storage scheme and part of it might be done by just persisting the normalized objects, which are much more compact (there's a lot of redundant information in most activities like "content" and "contentMap", some fields have a fixed value and we don't need to store that, some are repetitive and they can be broken up for storage, things like that), and although the indexing method is very fast, it does consume a lot of blocks (which is a kind of advantage because it makes hunting through the slush harder by introducing noise, though if it bloats storage overhead too much, there's not much point).
   
   I'm also doing it with the IPFS support disabled, as IPFS makes ingestion take about a hundred (SERIOUSLY) times as long. IPFS has been nothing but pain so far; I don't know what they are doing that makes their code behave this way. Just using flat files with split directories would be faster. The idea was initially that we could use IPFS as an extra channel: things could move through Revolver's protocol, or they could use IPFS, or ActivityPub, or stack those on top of Tor, possibly other means.
   
   Also, I would like to mention that I am continuing my trend of using technology that makes people frustrated with me: the ingestor, being glue code between Postgres and Revolver and having to parse JSON, is written in Ruby. (The reason it has to parse JSON is so that it can scan for the string "https://www.w3.org/ns/activitystreams#Public" in the to/cc fields and avoid dumping people's DMs to a public network; it also doesn't ingest followers-only posts, but that is just the ingestor.)
   
   At this point in the update, more things are popping into my head, "Oh, I should include that", and then "Oh, wait, did I account for $x?" and I keep falling down a rabbit hole, at the end of which I produce another paragraph, and it's either more or less information than anyone wants.