La nuova frontiera delle truffe telefoniche: l'ospedale
Uncategorized
1
Posts
1
Posters
0
Views
-
La nuova frontiera delle truffe telefoniche: l'ospedale.
Probabilmente hanno capito che al curriculum di Amazon e al lascito di Berlusconi non ci credeva nessuno.
L'azienda sanitaria informa di aver ricevuto diverse segnalazioni in merito a messaggi che invitano gli utenti a "mettersi in contatto con urgenza presso i nostri Uffici C.U.P. Centro Unico Polivalente al 899 XXXXXX per comunicazioni che la riguardano"
https://www.veronasera.it/cronaca/ulss9-scaligera-truffe-sms-mail-allerta-6-novmbre-2025.html
Gli ultimi otto messaggi ricevuti dalla Federazione
-
trwnh@mastodon.social ForumWG moving toward recommending that the root node's context MUST be inherited is not incompatible with 7888 per se, but 7888 does allow for creating your own context.
I think this might be a blessing in disguise. In situations where the root node doesn't contain a context at all, then creating your own context has its place. I am not sure how this would work when you try to do moderation actions against a context that isn't really yours though.
I'm discussing this with jesseplusplus@mastodon.social right now.
-
Seems like the conclusion is missing
-
-
A jury of your peers is lowkey goated when defending against prosecutorial overreach is the vibe.
-
@darth_biomech yes because I follow the RSS 8-)
-
Pinging related users for visibility: trwnh@mastodon.social silverpill@mitra.social melroy@kbin.melroy.org angus@socialhub.activitypub.rocks jesseplusplus@mastodon.social
-
Apologies in advance if I misrepresented anybody or missed any crucial bits of information.
Julian (myself) and Ted (tallted@mastodon.social) began the session discussing moderation tools in USENET There are comparable systems to how the threadiverse propagates content. Messages are sent to a remote server who is then responsible for distribution. In relation to moderation, there was more ambiguity. Local users could set up their own kill file but whether moderation could be done from the remote server was not discussed. We discuss more about actions done to contexts (aka topics, threads) Ted recommends a read through RFCs 2821 (SMTP) and 2822 (Internet Message Format) Dmitri (dmitri@social.coop) joins at or before this point, and points out that there continues to be confusion over the context property and @context. Example actions are offered: Removing a context from an audience, and locking a context from new contributions Re: crossposting, Ted discusses the need for implementor changes to allow for contexts to be a part of multiple audiences ed: much of the discussion at this point shifts away from ForumWG terminology and toward email nomenclature for ease of understanding. ForumWG nomenclature is used for these minutes Dmitri points out that a breaking change to AP might be needed in order to break apart header (addressing/recipients) and body Julian asks why, and Dmitri mentions signing difficulties wrt bto and bcc. Julian asks if anybody uses bto and bcc, and Dmitri says "yes, absolutely", and said we should check out darius@friend.camp's Fediverse Observatory for the answer Julian says that as currently implemented, resolvable contexts do not necessarily need to be inherited. Lemmy explicitly does not want to inherit contexts, and their published contexts always refer to a local representation (ping nutomic) Julian steps through an example. NodeBB A federates context /topic/1, NodeBB B receives the topic and assigns it /topic/4bdffa. A later Removes the context. B doesn't know what A/topic/1 is so needs to resolve it, get its' root post, and see if it matches any know context on B, then act on it. Ted and Dmitri caution that this is difficult and messy, and strongly recommend that the root-level context must be inherited
-
@lorenzo jazz?
