Look, if you are concerned about your instance's IP address leaking out and your reason is "privacy" then I'm going to go out on a limb an say you probably should take about five steps back and ask whether you should be running an ActivityPub based server _at all_. At least one that isn't on Tor and/or that you haven't specifically hardened.
I also have to wonder what is the subset of people who are using cloudflare and for whom that ip address won't just be us-east-1 or some equivalent.
@julian Yeah, this is my assumption as well. There's very little you can do to force this matter, and there's a lot of complexity in preventing server software from revealing this, so it isn't something your software can assume.
You can make it easier to hide that information, you can make it easier to use proxies etc, but you can't expect the software to do this for you. Installed software simply operates at the wrong level for that.
To answer the question: The standard that I have been told is that "anything can be an actor without declaring it, it just needs an inbox and outbox."
I think this is a terrible pattern, personally, but that's the standard.
Draft of my (to-be) FEP for audience targeting and filtering is up at https://github.com/larpconnect/featherpub/blob/main/feps/8f9c/index.md for those that are interested.
I haven't submitted as a FEP yet (and won't for a while), but that's the ultimate goal for it.
@julian That's… an excellent question.
So the requirement as I understand it is that the id must be publicly resolvable, which would imply a uniqueness constraint.
Still, the verbage doesn't say that it must be a publicly resolvable _to the object in question_ IIRC? I'd have to look this up to confirm it and am not in a position to do so right now, but that's an interesting question.
One of my least favorite patterns in software:
"We don't have a field for $foo, but we have `bar` that no one is using for its intended purpose, so rather than adding a `foo` field we're going to put $foo in `bar`"
You can find it all over software, and particularly in databases, and I see it a LOT in #ActivityPub development -.-
The protocol as it now sits will not keep you "safe" from threads in any meaningful way.
Repeat. After. Me.
The protocol as it now sits will not keep you "safe" from threads in any meaningful way.
I don't mean as in "it will not protect from a malevolent actor" sense. I mean in an ordinary, reasonable behavior sense.
#ActivityPub not only does not have the tools for this, it makes assumptions that are _fundamentally_ opposed to the kinds of protections that people seem to be seeking.
1/
ja, as you said: For _every_ non-threads fediverse account's private keys. My estimate on hachyderm came out to under 200 MiB, and for your median server it would be like… under a megabyte.
"I can fit this entire problem on my phone. No not an individual server's problem, that I could fit on my computer from college, _every_ server's problem simultaneously with good performance."
This is a good way to communicate it.
https://social.coop/@jsit/112207392247621081
That.
Also if you are struggling to build an app with speculative requirements in Java then you are building Java wrong. If that flexibility is desired then that flexibility is part of your needs and you design for it.
There are advantages and disadvantages there and there's certainly some things that would be easier or harder as tradeoffs, but you can do inflexible design in any language, and flexible design in pretty much any shop language.
@jenniferplusplus I'm very sympathetic for the social publishing problem.
I am a _lot_ less sympathetic for chat-related systems when XMPP is RIGHT THERE.
Part of my frustration with #ActivityPub and one of the things I find baffling giving everything else in it: the lack of tools for backpressure.
Backpressure is fundamental in building reliable distributed systems (c.f., Notes on Distributed Systems for Young Bloods). From a C2S perspective I get why it wouldn't need to be specified, but from a S2S _federated_ protocol perspective its absence is frustrating.
All that it says is to take care not to overwhelm _others_ and a bit on rate limits
This statement is going to live rent-free in my head for a long time to come, I suspect. #ActivityPub
One of about twenty examples, and another example of it being solved by people working _around_ the protocol more than they work _through_ the protocol.
Even then getting here required a lot people doing a lot of fighting over the course of multiple years, a lot of burnout, and involved a lot of derision and attacking of people who come from different online cultural experiences.
Ugggggghhhhhh. Whhyyyyyy.
I know I've ranted about this before, but still, looking at it tonight and just… why.
For those who are playing at home, two questions across a few examples should illustrate the frustration:
Q1. What should happen?
Q2. What do you think _would_ happen with implementations today?
Scenarios.
S1. Replying to two separate posts.
S2. Replying to itself.
S3. Providing a Link object reference.
S4. Providing a Link*
S5. Providing an Actor.
S6. Providing an Activity.
What actually happens isn't a mystery but it isn't pretty: https://funfedi.dev/support_tables/generated/in_reply_to/
@julian brb, implementing something that builds arbitrary B-tree structures of ActivityPub objects for Reasons
@julian I'm wondering how much processing systems naïvely do to understand the result here.
If I provide a link to a 10 MB object do you have safeties in place?
Does it traverse? If so that has lots of exciting edge cases.
If it refers into a loop will it catch that?
etc.
