rolle, 3 months ago to fediverse

User aaronrosspower at Threads:

”When Musk bought Twitter and there was that initial wave of people fleeing, Mastodon could've kept that momentum, and probably won out as the next big thing, if it'd (1) opened mastodon.social to registrations as the default server and (2) added quote posts. I'm convinced Bluesky's success was entirely because Mastodon didn't do (1) and (2), and while the Fediverse will still likely be the main decentralized network, once Threads federates, the process was significantly slowed and fractured.”

When will people understand that Mastodon or any other Fediverse app will not need to ”success” and be mainstream? I think we are not driven by profit and corporate gain. I think we will exist as long as there are people running their web services.

Please note: This is just my opinion. I have to state this, because I’ve been blocked for less. Comment if you agree/disagree.

#Fediverse #Mastodon #SocialWeb #Threads #Bluesky

arcanicanis, 3 months ago to random

Did you know: when you verify the signature on a digest, you should probably verify that the presented content (that the digest is supposedly of) actually hashes to the same value as the signed digest?

I’m just increasingly disgusted that it seems like the majority of developers are just collectively drugged, high, intoxicated, or some combination thereof, because I don’t understand how I keep stumbling into these things when I’m not even trying to pentest anything. Worse is that this is in a library that people are just blindly importing and trusting.

arcanicanis, 3 months ago to random

Why do we have both context (not to be confused with @context) and conversation? Is that another Mastodonism or Pleromaism? context is defined in the ActivityStreams vocabulary specification, while conversation is not. In production implementations, they seem to just reference the same value.

It would have been nice to just have either of those resolve to a Collection of some sort, such as containing all the objects within that context, and instead of needing another property (replies) to be a little less redundant.

silverpill, 3 months ago to random

#Mitra v2.9.0

https://codeberg.org/silverpill/mitra/releases/tag/v2.9.0
https://codeberg.org/silverpill/mitra-web/releases/tag/v2.9.0

Highlights:

• Generating Ed25519 keys for all accounts (in preparation for FEP-8b32 activation).
• Send notification to admin when a new user is registered.
• Legacy identity proofs are greyed out on profile page and a small button is displayed that triggers re-verification. In the near future Mitra will stop accepting legacy identity proofs (FEP-c390 identity proofs were implemented in 1.28.0 / 2023-06-26).
• Added "Federated" timeline (aka TWKN). Currently visible only to admins.

alex, 3 months ago to random

In theory, this Zapple Pay service would allow ActivityPub users to zap each other using the bridge: https://www.zapplepay.com/

https://github.com/benthecarman/zapple-pay-backend

I wasn't able to get it working yet: https://github.com/benthecarman/zapple-pay-backend/issues/20

But it's a really cool idea.

mikedev, 3 months ago to random

Containers

An Introduction to Conversation Containers

A conversation is a collection of messages with a common context. The ActivityStreams specifications define both collections and contexts, but very little guidance is provided on how to use them effectively.

This document specifies an ActivityPub compatible model for managing conversations as Collection objects with a common context.

In ActivityPub messaging, an actor generally creates a note and their server delivers it to their followers. On the receiving side, the message is analysed, and if it is found to be acceptable, it is placed in the receiver's inbox - which is implemented as a collection.

The top level post of a conversation (often a Note object) is defined as an object without an inReplyto property.

Most existing ActivityPub compatible software adds a context element to this top level post object in order to associate it with a given conversation; and this context is typically added to all children of the conversation in order to indicate their association. Replies can nest to abitrary levels and form a conversation tree if objects within the same context set inReplyTo to a message other than the top-level post, for instance to another Note object within the same context which already has inReplyTo set to a different object.

The microblog ActivityPub conversation model, which is used by Mastodon (and some other ActivityPub software) is considered "unconstrained". In that model, members of the conversation are free to send their replies to any audience (typically but not limited to their own followers), and this may lead to fragmented conversations as each node of the conversation may be distributed to completely different audiences. The actor creating a reply is also generally unaware if the conversation creator accepted the comment into the original conversation thread and in turn published the comment to the original audience.

In the conversational model, the same basic steps occur, but respects the rights of the conversation creator, or the actor that created the initial "top level" post of a conversation thread. These conversations take place within a specific audience - and may be moderated. Conversations adopting this model of interaction are considered "constrained".

Creating a constrained conversation

A constrained conversation is implemented as a Collection. FEP-400e provides a model for working with collections. In that proposal, ActivityPub objects which are created as part of a collection are indicated by a target "stub" property containing

• type -- (Collection or OrderedCollection)
• id -- a URL where this collection can be found
• attributedTo -- the id of the collection owner

In a constrained conversation, conforming implementations will implement FEP-400e with some very minor additions:

• In a constrained conversation, the target->id and the context are identical. This provides easy identification.
• In a constrained conversation, replies SHOULD only be addressed to the target->attributedTo actor.
• When receiving a correctly signed Add activity, checking that the id of the target is a collection owned by actor is slightly different from FEP-400e. This can be accomplished by fetching the Collection object and validating the attributedTo field.

Processing is otherwise identical. In the reference implementation of conversation containers currently under development in the streams repository, signed objects are often transmitted instead of just transmitting the ids, and these are signed using a combination of FEP-521a and FEP-8b32.

rimu, 3 months ago to kbin

Feels good to bring on of my favourite #Kbin features to #PieFed - domain blocking!

https://piefed.social/post/23470

silverpill, 3 months ago to random

https://github.com/mastodon/mastodon/security/advisories/GHSA-3fjr-858r-92rw

>Due to insufficient origin validation in all Mastodon, attackers can impersonate and take over any remote account.

A similar vulnerability was discovered and closed in Mitra. As far as I know, takeover is not possible here, only impersonation, but still it can be quite bad. Update to v2.8.0 if you haven't already

Other Fediverse software might also be affected

silverpill, 3 months ago to random

#Mitra v2.8.0

https://codeberg.org/silverpill/mitra/releases/tag/v2.8.0
https://codeberg.org/silverpill/mitra-web/releases/tag/v2.8.0

Various bugfixes and minor improvements.

Edent, 3 months ago to fediverse

🆕 blog! “Rebuilding FourSquare for ActivityPub using OpenStreetMap”

I used to like the original FourSquare. The "mayor" stuff was a bit silly, and my friends never left that many reviews, but I loved being able to signal to my friends "I am at this cool museum" or "We're at this pub if you want to meet" or "Spendi…

👀 Read more: https://shkspr.mobi/blog/2024/01/rebuilding-foursquare-for-activitypub-using-openstreetmap/
⸻
#ActivityPub #fediverse #FOURSQUARE #geolocation #OpenStreetMap

Idea/Help: P2P Monero Marketplace Over Nostr

TL;DR - I have an idea for a P2P decentralized marketplace using Monero and Nostr, but I’m looking for feedback and help....

How happy are you with monero.town?

The instance is now over half a year old and so far we’ve experience decent growth and minimal downtime....

mikedev, 4 months ago to random

I promise to add some more documentation before this is released, but I just want to keep providing updates on what we're doing here at the streams repository - especially as it concerns the fediverse and conversations.

The background is that we've always provided what I'll call "containerised conversations" in earlier iterations of the fediverse (several years prior to the emergence of Mastodon and ActivityPub). These are quite different from microblogs - which aren't really conversations at all, but more like people throwing posts into space kind of willy nilly. Each post and each comment can be addressed to a completely different audience.

In our alternate implementation of the fediverse, conversations are contained and more coherent. We do this by directing all comments back to the person who started the original post of the conversation, regardless how many levels of nested comments. This person "owns" the topic and is responsible for distributing all the comments to the original audience. This is how one implements restricted conversations - sometimes called circles or aspects - as well as private groups; which are very difficult to accomplish in a microblog platform. This is why only a very small number of fediverse implementations support these concepts.

When we brought our work to the ActivityPub fediverse several years ago, it conflicted with the microblogs, who quickly dominated the space. So we provided some ActivityPub extensions to continue our work and still use these very important conversational constructs.

Fast forward a few years, and we've been squeezed into a corner, and what we consider a superior way of managing "restricted" conversations has been relegated to obscurity. But during this time, a handful of ActivityPub developers have been working on tools which also provide this functionality, in better ways that in our original extensions. So we're updating our repository to accommodate these changes.

This work is described in the following Fediverse Enhancement Proposals (FEPs). The first two deal with signatures and retires the earlier flawed LD-signatures. This allows the content owner to relay private content to other members of the conversation, while providing proof that the author is not being spoofed. HTTP-Signatures don't work in this context because the original author may not have granted third-party permission to access the content directly and may not even be aware of who is involved in the conversation. The audience belongs to somebody else. It is being relayed by the conversation owner who does have permission to access the content directly.

FEP-c390: Identity Proofs
FEP-8b32: Object Integrity Proofs

The next two proposals deal with working with contextual collections. In this body of work, every conversation is a collection. Anybody can create a post, but only the owner of a conversation can add a response message to their conversation and distribute it to a pre-defined audience. This is accomplished by turning the conversation into a Collection object.

FEP-400e: Publicly-appendable ActivityPub collections
FEP-7888: Demystifying the context property

The end result is that the fediverse is able to support a wide variety of interactions which don't fit in the microblog or 'Twitter' model of interaction. There also may be times when one model works better for some conversations than others. Perhaps a simplified description would be to call these "constrained" or "contained" conversations, and the traditional microblog usage might be called "unconstrained" because conversations and their audiences have no binding to each other. Contained conversations create this binding and creates a conversation as an atomic property in the fediverse. It is also possible to "fetch" this container and access the entire conversation (all activities and comments) across all participants. This is not practical or possible using the unconstrained model. In any case, this is what we're doing. It makes things like the old Google+ "circles" and features like Facebook style private groups available to the fediverse without clumsy workarounds.

And best of all, it doesn't break compatibility with microblog software. It just provides additional functionality and features which that model of interaction cannot provide, as well as allow both mechanisms to co-exist without breaking each other's expectations of visibility and privacy.

Or put in another light, we support all of Mastodon's weird and non-standard privacy modes because we choose to. Some projects do not, and this is permitted by the relevant specifications. This just ensures that everybody supports ours - because we aren't giving them a choice.

devnull, 4 months ago to fediverse

One quick question about instance keys... I have private and public keys generated for individual user actors in my implementation, and that works when attempting to access resources from an instance with AUTHORIZED_FETCH enabled. If I need to retrieve content without a local user context, would I be making the call with an "instance level" public key/signature?

That was my interpretation, but would appreciate confirmation 😃

#activitypub #fedidev #nodebbActivityPub