I don't have an answer for Edits; I don't plan to support them initially, maybe ever. I don't think it's a good idea. But the way a Delete works internally versus how it tries to convey this to the network, like, your activity stream is a list, as much as is needed can be backfilled, but deletion is O(n) for the actor doing it and O(1) for everyone else. I'm not sure what's a good way to convey that back and forth to fedi, you know, I don't wanna get stuck processing some Delete-flood from someone with 400k Creates on some masto instance.
(I think I had other stuff to say here but I don't remember. Weekend before Halloween, couch, bourbon and pizza, woman, Dawn of the Dead, Day of the Dead, really great movies (the remakes sucked). Anyway, fell asleep on the couch, put on I forget what, and cannot remember what I was supposed to put in this box. Rather than feeling refreshed after a day off, I feel sluggish and off my game, so I figure weekends and vacations are for suckers.)
> Fediverse needs to migrate to something else and EdDSA seems to be the best option (according to the rough consensus among fedi devs). Also, Ed25519 key size is very small, that's pretty cool.
Ah, okay. Reasonable. I'll put it on the list; I had seen support for it in Honk but because Pleroma didn't have it, I just put a note in a comment and ignored it.
> But the FEP should say something about Accept header and media type, I don't see any way around that.
The Accept header mechanics don't need redefining; you just say it's served with this MIME-type, right, and then servers that handle Accept headers correctly will handle it correctly. If you're worried an informal reading will make sloppy implementations create a de facto bad standard, then you could put a note in that the client and server are expected to implement HTTP-compliant semantics.
> The exact same requirement exists in ActivityPub spec.
It's broken in the ActivityPub spec. It is not just broken in the ActivityPub spec, but it is irreparably brain-damaged. Feel free to skip these next two paragraphs; I explain why what the ActivityPub spec says can/should be ignored, but I also cannot type this without ranting.
Why call it the "Accept" header if the server isn't going to treat it that way? If the ActivityPub spec says that a byte is nine bits, it's exceeded its authority. cwebber wants to treat it like a secret handshake because cwebber is a greasy illiterate dingus and this is network software: fuckups take years to resolve.
"Accept:" is intended for content negotiation, not like a secret handshake like cwebber seems to think: the idea was initially that a server can represent content in several possible forms, clients say which forms they prefer and indicates preference, the server tries to give the client one of its preferred forms. Support for parameters *besides* preference was explicitly dropped, so the ActivityPub spec if not just broken, it fails to comply with an obsolete version. You sure as hell don't put some stupid fucking XML-style wank in there where you cram a *namespace* into the Accept header. Dear god, I haven't seen a worse idea than ` The client MUST specify an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type in order to retrieve the activity.` in forever.
Ahem.
> How do you prefer it to be written?
If I were writing it, I'd leave it out: you take it as read that if they are doing web server software, they should be following HTTP's semantics. Maybe a "See also RFC 9110 sections 8.3, 12, and 15.5.7" or something. You don't specify that the client MUST send some value for the Accept header, you take a well-formed HTTP message from the client, the semantics are in the spec for what you've got to do when the message is well-formed but semantically wrong, and you've not broken anyone's clients as long as you stick to the spec. So you say what the server should do in case the message is well-formed but the semantics specify something the server can't do, and you refer to the other specs for semantics and behavior of lower layers instead of re-specifying it.
Again, you know, you're the one putting in the work so take anything I say about as seriously as is warranted: here are my thoughts.
> Maybe there's a better way to provide location hints,
Well, I think, like, you embed the location hints in the user's profile but you expect that if someone has the object, then they can figure out how to get the user. You don't get an object out of context, it's part of someone's stream.
I think maybe "how the URI is constructed and how it should be interpreted semantically" should probably be a different document.
> How do you process Update activities then?
Updates update the Actor, and those are trivial, because the actor's metadata is a slot, not a stream. Other stuff, longer answer, and food is ready.
@PunishedD@crunklord420@i@judgedread@mint I don't know, I scribbled that stupid Markov bot that scrapes timelines, and I had the goddamn sense to make sure that if you wanted to crank down the rate-limit, you had to tweak the code, and if you want the UA to impersonate a browser, you've got to add it. I didn't make the example config pretend to be Chrome so that it's *more* effort to make the bot behave than to make the bot lie.
@silverpill@frogzone@jeffcliff@feld I haven't kept up with it. I have some notes but you can feel free to ignore them; I don't want to get in the way of some people doing a thing. Wherever it lands, I'll try to make sure that we can interoperate without breaking the FEP semantics if possible, but some places, it's not going to be possible. So, here are the notes (and quick read, so I may have missed things or I may have the wrong idea, because the stupid DDoS yesterday cost me a lot of time and I'm trying to catch up today):
If it's a new protocol, I don't know why we're still doing a fragment for the key ID. I don't love JSON (anti-web) but we've got to live with it; on the other hand, I don't want to abuse JSON or URLs.
> Ed25519
I'm using RSA keys so that it's easy to port myself from Pleroma. It is entirely possible that there is something I am missing and that we shouldn't be using RSA keys; maybe key algo is overspecifying.
> /.well-known/apgateway
I like this, but I wonder if there's a way around it without hard-coding another URL.
> The client MUST specify an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type.
This is actually objectively wrong. I don't know why this should be done rather than using the HTTP standard interpretation of "Accept:" headers. If the client doesn't include "application/ld+json" or "*/*", then you just return a 406. The way Pleroma/Masto do these things kind of shits on RFC 2616 and I really love RFC 2616. (This is why I'm not doing the terrible sniffing algorithm to differentiate between a browser and another server on the /objects/$id URLs.) If there is a good reason, maybe, but if we're tossing out the well-defined HTTP semantics that HTTP clients rely on, we can't call it HTTP.
> Portable actors
This looks roughly compatible with what I am doing; there's an ID for an actor, the network protocol is used to find the actor, etc., and then to use an AP gateway, you sign a request to be canonically located on one, the owner of that domain approves or ignores, and that's the PoT for your account as far as any other AP server knows. So your /inbox and /outbox, the server with the responsibility for delivering your posts when it sees new ones, etc.
So this section looks like it's roughly compatible with that. Instead of ordered gateways, Revolver can just send one gateway.
> Portable objects
This part, I don't know how I'm going to manage this. The "attributedTo" being tied to the gateway URLs, and then those potentially changing, that's going to be a mess with content-addressed storage. If you create a new activity by signing the head of a tree that contains pointers to objects in a stream, then those objects changing (e.g., because a gateway changed) is going to make hopping computationally infeasible once you have a long enough history (which is going to be almost all of the initial users, since they will mostly be people on FSE/bae.st that follow the move to Revolver).
> Presumptuously assuming here that you need Erlang and Elixir for #Pleroma and precisely nothing else,
You do need those to hack on Pleroma because Pleroma is written in Elixir, but there are dependencies that are written in C, too. There's probably other stuff in there.
> cuz I had literally never heard of either of those languages before getting involved in #fedi
I did some Erlang at an old job; I'd never done Elixir but I saw people talking about it.
It gets easier to pick up languages the more you pick up anyway. And then you know, like anyone can pick up awk in 30 minutes, most of the shells anyone uses are scripting languages you can pick up gradually.
@KuteboiCoder@mint@i@feld@j Ah, Elixir's not hard to pick up if you know Erlang. Elixir is definitely not my favorite language but I've never regretted learning a language, JavaScript aside.
@i@feld@j@mint How tricky is it to just call Erlang stuff from Elixir? Seems relatively easy, right? (Unless I am forgetting something, I think you can just call it directly.)
Resident hacker, leader of the fsebugoutzone.org coup of the FSE Autonomous Zone, BOFH of freespeechextremist.com, and former admin of FSE before the establishment of the FSE Autonomous Zone. Launching a guerilla war against myself from this bunker.I'm not angry with you, I'm just disappointed.I am physically in Los Angeles but I exist in a permanent state of 3 a.m.I have dropped a bytebeat album, feel free to DM me for a download code or a link to a tarball: https://finitecell.bandcamp.com/album/villain . There is a chiptunes album there, too.Revolver is coming: https://blog.freespeechextremist.com/blog/revolver-kickoff.htmlWar has changed: https://blog.freespeechextremist.com/blog/update-and-roadmap.htmlThe usual alt if FSE is down: @p@bae.st or @p@shitposter.world.