Piero Bosio Social Web Site Personale

@helge @julian for example, consider that activitystreams was designed to describe streams of activities, and activitypub was designed to publish activities. yet fedi discards activities and only unwraps them for their "side effects". then why use activitystreams or activitypub at all? any information model, data model, processing model, etc inherent to activity streams is being ignored.

@helge @julian what does fep-2277 say that you can "enforce"? reading over the fep, it seems to not have any requirements, but it's also misguided in its rationale -- it presents things as problems when they aren't problems, and concludes things that aren't conclusive. why should actor/activity/object/collection/etc be disjoint? why can't you Update a Collection? why can't you Announce an actor?

the issues are not of "validity" but of "understanding". people misuse and ignore definitions.

@helge The point is you don't know what information someone needs to do anything useful. Your use case is not their use case. Your understanding is not their understanding. Claiming data is "invalid" just because you don't understand it or you don't find it useful is missing the point.

What you really want is alignment between your understanding and your audience's understanding, and if you want to enable their use case, then give them enough information. But you can't know your entire audience

@helge it's easy for data to be valid. it's another thing entirely for it to be useful.

either i missed the boat on this fortune cookie or i gotta wait another 11 months

the state of the smartphone market is one of the first big things that radicalized me tbh. it made me realize that people's needs will go unmet if they are not profitable.

i mean, show me a one-handed phone with a 5g connection running at least android 14 (so i can use enpass to store my passkeys) and 5h screen-on time, a camera that isn't a potato... it just doesn't exist, and won't exist, because all the profit is in behemoths that are 76mm wide. these days "small" is 72mm.

as always i have to preempt the question "why 70mm width"

my hands hurt so much. phones keep getting bigger and my hands keep staying the same size. 70mm is already a compromise for me, as my real max would probably be 67mm, and i would prefer 65mm or even 60mm. heck, if my iphone se 1st gen wasn't stuck on ios 15, i would still be using it! if my xperia x compact hadn't stopped getting radio signal i would still be using it. both those phones are from 2016. everything after that point sucks.

re: https://www.tmonews.com/2025/10/t-mobile-to-start-phasing-out-4g-lte-network-by-2026/

idk what i'm going to do for my phone situation in the future because the phone market left me behind in 2016. when those lte phones stop getting adequate signal, there probably won't *be* any nr phones within my parameters...

it's already bad enough knowing that just two params -- max 70mm width and support for 5g band 66 -- already leaves me with only 12 results: https://www.gsmarena.com/results.php3?nWidthMax=70&s5Gs=66

at this point, i'm clinging to my sony xperia and iphone mini until they die.

the duality of "more people need to see this" and "i'm tired of seeing this"

@silverpill @reiver @xmppbrasil @helge @badrihippo @zoul problem with side effects and multiple clients is that you need to coordinate actions or otherwise make everything idempotent and order-independent. typical mastodon monolithic case can be thought of as a single client force-attached for every actor on the server with no option to attach other clients.

@silverpill @reiver @xmppbrasil @helge @badrihippo @zoul i think with the way you're describing this case, it would really end up being a collection server or endpoint, right? that makes sense if there's a requirement to dynamically page collections. if you're willing to accept static collections, then it simplifies things greatly

but you could still keep side effects if you somehow signaled which clients attached to which inboxes and what they do. a "default client" can manage AP side effects

@reiver @thisismissem but more importantly: before defining such terms, consider what you are actually trying to do with them practically. how do you intend to process them? what's the use case? which information do you need and why? ask yourself those questions first.

@reiver @thisismissem instead of making up properties that don't exist in a namespace that you don't own, you should use something that someone else already defined properly within their own authority, or otherwise define stuff under your own authority.

for example: CITO is an ontology for citations http://purl.org/spar/cito

see also http://www.w3.org/ns/prov#Quotation or http://purl.org/spar/fabio/Quotation

@erincandescent @ikuturso @mcc @jrose isn't plc basically custodial keys?

@mcc @erincandescent @ikuturso @jrose uhhhh

"key management hard", basically

@esoteric_programmer @lrhodes @mat @mcc @alter_kaker you are *supposed* to "convert" the user.domain.tld to did:plc:blah, but you can still construct references against user.domain.tld. but you're not supposed to. but every user-facing component only shows you the user.domain.tld instead of the did:plc:blah, so if you're just copying from your address bar, you are going to get the "wrong" identifier most likely.

it has the exact same properties as letting a dns name lapse and get reassigned.

@erincandescent @ikuturso @mcc @jrose i think you could replace it with signed updates but in doing so, you've basically just wrapped around to needing a pki

@mcc ah, i missed that part ^^;

@mcc @erincandescent @ikuturso @jrose i think this effectively amounts to "just use a dht that everyone agrees on"

@mcc @erincandescent @ikuturso @jrose right now the practical consideration for migration is one of the following:

- you have a did:plc and want to migrate to did:web
- you have a did:web and want to migrate to another did:web
- you have a did:web and want to migrate to did:plc

none of the three are currently possible, you will lose all your follow relations etc even if you replicate the exact same content or serve the exact same data repo