You cannot use a mastodon app as a lemmy client, but you can view lemmy communities by opening them as if they are profiles. For example, open @fediverse@lemmy.world and it will show up as a user, but it will be the communitiy's posts.

You can mention it in a post to forward the post to the community as well.

Toward the end of the Cretaceous, flowering plants (angiosperms) transformed ground habitats, making them more diverse. While it was known that tree-dwelling mammals faced challenges after the impact of the asteroid, it wasn’t clear if mammals adapted by becoming more ground-based. Earlier research primarily analyzed complete skeletons to study how ancient mammals moved.

A recent University of Bristol study reveals that many mammals were transitioning to a ground-based lifestyle before the asteroid’s impact. By analyzing small bone fragments—an approach never used to study whole communities—the researchers examined fossils from museums in New York, California, and Calgary. Their findings show that a significant shift toward ground-dwelling occurred several million years before the mass extinction that ended the age of dinosaurs.

Why crocodiles have changed so little since the age of the dinosaurs?

New research by scientists at the University of Bristol explains how a ‘stop-start’ pattern of evolution, governed by environmental change, could explain why crocodiles have changed so little since the age of the dinosaurs.

^{Pranjal Malewar (Tech Explorist)}

A new security fund opens up to help protect the fediverse | TechCrunch
Sarah Perez
4–5 minutes

The fediverse, also known as the open social web that includes Mastodon, Meta’s Threads, Pixelfed, and other apps, is ramping up its security. On Wednesday, a nonprofit focused on bringing governance to open source projects, the Nivenly Foundation, announced the launch of a new security fund that will pay those who responsibly disclose security vulnerabilities that affect fediverse apps and services.

While all software can have security issues, Mastodon — an open source and decentralized alternative to X — has fixed numerous bugs over the years, leading to the need for such a program. Another issue found in the fediverse is that many servers are run by independent operators who don’t necessarily have a security background or understand best practices.

Already, the Nivenly Foundation has helped a few fediverse projects set up their basic security vulnerability reporting process, and now it’s looking to distribute small payouts to anyone who responsibly discloses other security vulnerabilities that may still be in the wild.

The payouts will total $250 for vulnerabilities with a vulnerability severity score (known as CVSS) of 7.0-8.9 and $500 for more critical vulnerabilities with a CVSS score of 9.0 or greater. The funds for the payouts come from the foundation, which is supported directly by members — which includes individuals as well as other trade organizations.

The vulnerabilities themselves are validated by acceptance from the fediverse project leads as well as public records in vulnerability disclosure (CVE) databases.

The fund is currently in a limited trial after the discovery of a security vulnerability in the decentralized Instagram alternative, Pixelfed. Open source contributor Emelia Smith came across the issue, and the Nivenly Foundation paid her to fix it, she explains.

A more recent issue came about when Pixelfed’s creator, Daniel Supernault made the details of a vulnerability public before server operators had a chance to update, which would have left the fediverse vulnerable to bad actors, she says. (Supernault has already apologized publicly for his handling of the issue that had affected private accounts.)

“Part of the program is…education for project leads, helping them understand why responsible disclosure practices for security vulnerabilities are important,” Smith told TechCrunch. “We came across several projects that just said ‘file security vulnerabilities in our public issue tracker,’ which absolutely isn’t safe, as any malicious actor watching that repository would now be able to attack instances of that software,” she added.

Typically, the common practice is to disclose minimal information about a vulnerability, giving server operators time to upgrade, Smith said. However, this requires that project leads understand security best practices.

In the case of the Pixelfed issue, for instance, the Hachyderm Mastodon server, which has over 9,500 members, decided it needed to defederate (or disconnect from) other Pixelfed servers that hadn’t been updated in order to protect their users.

With this new program designed to follow best practices around the disclosure of vulnerabilities, the need to defederate to protect users may become less common.

Sarah has worked as a reporter for TechCrunch since August 2011. She joined the company after having previously spent over three years at ReadWriteWeb. Prior to her work as a reporter, Sarah worked in I.T. across a number of industries, including banking, retail and software.

I'm not sure why any of this is surprising. The US was perfectly fine letting China manufacture all the things. That manufacturing know-how leads to design know-how. The desire by US corporations to keep wages low or eliminate US labor entirely to use outsourced manufacturing leads to this.

It isn't just military hardware: it is products across entire industries. China is producing good ones, and even when they aren't, they're producing them at volumes the US could not dream of touching.

For information, Framasoft is a french non profit that fights really hard to protect our privacy rights and the right to free software.
They have a bunch of FOSS apps to replace some of the FAANG services, they're also the creators of PeerTube if I recall correctly.

@Framasoft@framapiaf.org

@framasoft@framatube.org

@Framasoft@lemmy.world

framasoft.org/en/

Framasoft

Framasoft is a not-for-profit popular educational organization, a group of friends convinced that an emancipatory digital world is possible, convinced that it will arise through actual actions on real world and online with and for you!

^{framasoft.org}

Some notes for things I want to bring up regarding agenda items:

SIOC: Semantically Interlinked Online Communities as prior art

Predates ActivityPub, was submitted to the W3C, has evolved up until ~2018 in some form. Concepts that could be relevant for Forum TF work:

sioc:Item is directly associated with a sioc:Container, whereas as:Object is included in an indirect list of items within as:Collection

Containers vs Collections
For more on the difference between a Container and a Collection, see RDF Schema sections 5.1 and 5.2

A Container has open membership. There might always be more items in a container that are unknown:
<#Bag> <#red ball>.<#Bag> <#green ball>.<#Bag> <#blue ball>.# We do not know if the bag contains any other balls, such as a yellow ball.
A Collection can have closed membership. For example, Lists can be terminated with a nil element.
<#List> rdf:first <#A>.<#List> rdfs:rest rdf:nil.# We know that the list does not contain any more elements beyond A.
The way this is applied in SIOC is like so:
<#Item> sioc:has_container <#Container>.<#Container> sioc:container_of <#Item>.
The way this is applied in ActivityStreams is like so:
<#Collection> as:items (<#Item>).# There is no way to signal that the Item is part of the Collection, and it is not expected that collection items will expose links back to every single collection they are a part of.

sioc:UserAccount, sioc:Post, sioc:Thread, sioc:Forum, sioc:Site

• A Post has_creator UserAccount.
• A Post has_container which can be directly a Forum, or it can be something like a Thread (which can itself has_container of a Forum).
• A Forum can has_parent of another Forum, if wishing to model subforums.
• A Forum can has_space of a Space (like a desktop or file share), or in more concrete cases can has_host of a Site.

Mapping to AS2-Vocab?
If we roughly map this to AS2-Vocab we might get something like this:
@id: @type: [as:Person, sioc:UserAccount]@id: @type: [as:Person, sioc:UserAccount]@id: @type: [as:Note, sioc:Post]as:attributedTo: sioc:has_creator: as:content: "Hello"sioc:content: "Hello"as:context: sioc:has_container: @id: @type: [as:Collection, sioc:Thread] # caveat where as:Collection has spec issuesas:attributedTo: as:audience: # maybe?sioc:has_container: sioc:container_of: @id: @type: [as:Group, sioc:Forum]as:attributedTo: # i guess?sioc:has_moderator: sioc:has_host: @id: @type: [as:Service, sioc:Site] # idk about this onesioc:host_of:

Subtypes of forums and posts

From SIOC types module:

• Forum: ArgumentativeDiscussion, ChatChannel, MailingList, MessageBoard, Weblog.
• Post: BlogPost, BoardPost, Comment, InstantMessage, MailMessage, WikiArticle.

Protocol considerations

We probably want to separate eventually the idea of "i authored this" from "i have authority over this", especially if a forum "lives" somewhere on a host.
Comparison to NNTP / NetNews protocol / Usenet network
RFC 5536 defines an article format for sharing RFC 822/2822/5322 style Internet Messages with mandatory headers:

• Date (as:published)
• From (as:attributedTo)
• Message-ID (@id)
• Newsgroups (as:audience??)
• Path (no analogue, represents the path taken as the article is shared across newsgroups? so an ordered list of where it was shared/reshared from?)
• Subject (as:name or as:summary, but probably not required for AP Forum TF)

RFC 5537 describes architecture for distributing such articles as Internet Messages:

• A "posting agent" passes an article to an "injecting agent"
• The "injecting agent" injects the article into a group
• A "reading agent" can then fetch articles from a group

RFC 3977 describes NNTP protocol:
<pre><code class="lang-auto"> Example of a successful posting: [C] POST [S] 340 Input article; end with <cr-lf>.<cr-lf> [C] From: "Demo User" <nobody@example.net> [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Organization: An Example Net [C] [C] This is just a test article. [C] . [S] 240 Article received OK Example of an unsuccessful posting: [C] POST [S] 340 Input article; end with <cr-lf>.<cr-lf> [C] From: "Demo User" <nobody@example.net> [C] Newsgroups: misc.test [C] Subject: I am just a test article [C] Organization: An Example Net [C] [C] This is just a test article. [C] . [S] 441 Posting failed Example of an attempt to post when posting is not allowed: [Initial connection set-up completed.] [S] 201 NNTP Service Ready, posting prohibited [C] POST [S] 440 Posting not permitted</nobody@example.net></cr-lf></cr-lf></nobody@example.net></cr-lf></cr-lf></code></pre>
We could probably do something with Announce and/or Offer or similar?

In a simple model where there are only groups and posts, no threads (a la FEP-1b12)

• Offer Note to Group
• Group can then accept/reject the post and issue an Announce?

Once we introduce threads, we will want to have more control not at the group level but at the thread level.

There is a bit of a philosophical question of approach here -- given that the core mechanism here is fundamentally notification messages via LDN (POST to inbox), although it is arguable that Activity payloads gets used as a sort of JSON-RPC more than as a notification... should we therefore optimize for a notification-oriented flow or a more procedural flow instead?

In a notification flow, we just want some resource to be aware that we have made a new post, and they can then distribute it or not. Say something simple like this:
id: actor: type: Announceobject: to/cc/audience/bto/bcc: id: actor: type: Announceobject: audience: [, ]cc:
but instead of addressing or targeting you might instead address or target ? whichever application is listening to the thread's inbox then handles the cascade of distribution upward:
id: context: id: context: # ?audience: # ?attributedTo: followers: id: audience: followers: id: members: # extension property/collectionfollowers:
what is desired is roughly this:

• Announce to the
• the Announces to...
  
  • ?
  • ?

  
  

• the might also Announce to and to

the challenge is in avoiding duplicate traffic, so ideally this would be under the control of a single controller who issues a single Announce to the sum total of the accumulated audience:
id: actor: type: Announceobject: to/cc/audience/bto/bcc: # ... some chain of events later...actor: type: Announceobject: to/cc/audience/bto/bcc: - # - is already aware? - - - - - -
this is essentially an event driven architecture. you'd need to choose between "exactly once" and "at least once" delivery.

concerns:

• what ends up in shares collection? for a single share action, do we end up with multiple Announce activities in there?
• who gets addressed? inbox forwarding? this probably shouldn't be the responsibility of to have to be aware of every single downstream/upstream recipient, right?

C’mon we all know what this is: Remote Uyghur organ harvesting. /s

I swear they’re just flexing now. Next thing you know it’ll be autonomous robotic surgery on the Moon.