silverpill

joined 3 years ago
[–] [email protected] 3 points 2 weeks ago

@Teknevra It can be done with FEP-ae97:

https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md

Which enables shared identity and seamless migration as you describe, but I don't think traditional web login needs to be abandoned. Fediverse will support both types of identities.

@fediverse

[–] [email protected] 1 points 3 weeks ago (1 children)

@julian I am affected by it as well, which is strange because previously federation with PeerTube worked fine. Perhaps they broke it in a recent release

[–] [email protected] 1 points 3 weeks ago (3 children)

@julian Did you report this bug to PeerTube?

 

Fediverse tech roadmap 2025

One year ago I published Fediverse tech roadmap for year 2024. How did we do?

  • Data portability. FEP-ef61 has advanced significantly. Compatible IDs were introduced, which make portable objects fully compatbile with existing ActivityPub implementations. Identity can be represented using any DID method, not just did:key. Security of the protocol has been studied extensively. And most importantly, there are now two interoperable implementations: Streams and Mitra.
  • End-to-end encryption. An end-to-end encryption system is being developed for social networking platform Enigmatick. It is based on the Olm protocol, which is also used by Matrix.
  • Connectivity. A big improvement came from Mastodon, which now notifies its users when relationships are severed by moderation actions. ActivityConnect AP-to-AP bridge was developed, but it didn't see much use, indicating that the problem it attempts to solve is not serious.
  • Moderation / spam resistance. Two different conversation moderation mechanisms emerged: Conversation Containers (implemented by Streams and Hubzilla) and Interaction Policies (implemented by GoToSocial).
  • Scalability. The number of platforms implementing FEP-8b32 is slowly increasing but the biggest ones still don't sign their activities (or use non-standard LD signatures). Some preliminary work on optimizing media delivery was done in FEP-1311: Media Attachments.
  • Plugins. Lemmy developers are discussing WASM plugins in an RFC. A WASM-based MRF was implemented in Kitsune.
  • Discovery. Mastodon introduced fediverse:creator OpenGraph tag. Relay protocols were documented in FEP-ae0c, and ActivityPub Discovery report was published. Several projects are working on Starter Packs similar to ones used by BlueSky platform.
  • Developer experience. Fun Fediverse Development project continues to improve, and now provides support tables for many protocol features. ActivityPub and WebFinger and ActivityPub and HTTP Signatures reports were published, as well as FEPs about Origin-based security model and various features such as OpenWebAuth and Emoji reactions. FEDERATION.md is becoming more popular, the number of projects using it nearly doubled in 2024.
  • Groups. Conversation Containers were implemented in Streams and Hubzilla, and FEP-171b: Conversation Containers was published. FEP-1b12 and Conversation Containers have many similarities, and the work on further alignment is ongoing.
  • URL handlers. No significant progress.
  • Synchronization of replies. Both FEP-1b12 and Conversation Containers naturally lead to synchronized conversations.
  • Markets. No significant progress.
  • Quoting. FEP-e232 is now supported by 8 platforms.
  • Forge federation. Forgejo implemented federated stars, and the development of other features has started.

I think the work on these problems should continue in 2025, especially in the following key areas:

  • Conversations and groups. FEP-1b12 and Conversation Containers are good solutions and may eventually become one because their differences are mostly superficial.
  • Data portability and Nomadic identity. A lot of work still needs to be done. Some aspects of FEP-ef61 are underspecified, for example media storage. A fully featured nomadic client (FEP-ae97) has not been developed yet and migration of data between implementations has not been demonstrated. I would also like to see experiments with peer to peer networking (FEP-ef61 is designed to be transport agnostic, this means HTTP transport can be replaced with something else, such as Iroh) and cross-protocol interop (identities created for Nostr and ATProto are compatible with FEP-ef61).
  • ActivityPub C2S API. Although standard client-to-server API is not popular among developers, the work on it should continue because nomadic client-to-server API (FEP-ae97) is very similar.
  • End-to-end encryption. I think that adoption of solutions developed for other protocols is a good idea. A custom solution may take many years to develop.
  • Developer experience. Code reuse in not common in Fediverse: most developers implement ActivityPub primitives themselves. Libraries for all programming languages need to be created, along with online validators, testing tools and good documentation.

#ActivityPub #Fediverse

[–] [email protected] 2 points 1 month ago

@Fitik @Teknevra Tipping will also be supported in the future (in addition to subscriptions).

And people on other platforms may put addresses in profile fields (Lemmy doesn't have them yet?). Mitra displays a donation icon when address is detected (the name of the field should be like $BTC).

@fediverse

[–] [email protected] 1 points 1 month ago

@julian Yes, this is secure because web origin remains the same. I simply remove the fragment, it works for everything except GoToSocial.

Nevertheless, mismatch between signature keyId and publicKey.id is a bug.

cc @peertube

[–] [email protected] 0 points 1 month ago (1 children)

@Irelephant @activitypub Yes, IP addresses are often used in development and testing environments. I haven't seen such servers in the global network though

[–] [email protected] 1 points 1 month ago (1 children)

@julian

>As it is a Lemmy community, it only shares content, and does not produce any of its own.

Is NodeBB different? I follow a category on your server and it seems to be doing the same thing as Lemmy (except your implementation announces not only a top level post but replies too)

[–] [email protected] 1 points 1 month ago

@julian

>updates by WG members re: non-as:Note support in Mastodon

I don't know if it has already been discussed, but funfedi.dev has a very useful support table for HTML tags:

https://funfedi.dev/support/_tables/generated/html/_tags/

[–] [email protected] 1 points 2 months ago

@julian You're right, the choice of software shouldn't matter. Our goal is seamless interoperability.

@trwnh @thisismissem @mro @jupiter_rowland @renchap @scott @AltCode @leroy @Kichae @scott

[–] [email protected] 1 points 2 months ago

@julian @pitaj

I can see them. Good work!

[–] [email protected] 1 points 3 months ago

@julian This pattern can also be used in Accept and Undo activities:

{
  "type": "Undo",
  "id": "https://social.example/activities/undo/1"
  "object": {
    "type": "Like",    # or "Follow"
    "id": "https://social.example/activities/like/1"
  }
}

 

How many domain names your government needs to block in order to censor an entire network?

Bluesky: 1 domain name
Nostr: 680 domain names, but blocking 10 most popular relays and hosted clients would probably be enough to kill it
Fediverse: more than 20000 domain names

#Fediverse #Censorship

 

Article Interop WG: How to represent titles?

Should title be inserted into Article.content as an <h1> tag, or should it go to Article.name?

@article_interop

view more: next ›