silverpill

silverpill, 4 months ago (edited 4 months ago) to random

Fediverse tech roadmap

This is how I want our network to evolve in 2024. Some of the things listed here may have been implemented already by a small number of projects, but more work is required on standards and interoperability.

• Data portability. In my opinion, this is the most important problem. I'm in favor of FEP-ef61, which also solves identity portability and unlocks many new features.
• End-to-end encryption. MLS has become a standard, and it would be wise to adopt it. Issue 3 at fediverse-ideas provides a good overview of what we have at the moment (not much). Some variation of FEP-ae97 is likely needed to make end-to-end encryption work.
• Connectivity. Improving connectivity means fighting indiscriminate instance-level blocks, expanding to overlay networks (Tor, I2P and others), maybe also developing standards for bridges. In many ways, these tasks are linked to data portability.
• Moderation / spam resistance. Anything other than "list of instances I don't like" would be a huge improvement. Fediseer is an interesting development, but still leaves a lot to be desired. Additionally, standardization of reply controls is needed. FEP-5624 exists, but the mechanism described there has many flaws.
• Scalability. How to publish to 1M followers from a single-user instance running on cheap hardware? FEP-8b32 should make various optimizations possible (inbox forwarding, efficient reposts, etc).
• Plugins. Something like Pleroma MRF, but cross-platform (e.g. Wasm-based). Also, pluggable timeline algorithms.
• Discovery. Content discovery on small instances: relays and related standards, decentralized search.
• Developer experience. Documentation of de-facto standards (HTTP signatures, WebFinger). Simplified ActivityPub spec. Error reporting.
• Groups. We have several competing standards for groups: FEP-1b12, FEP-400e, Mastodon developers are working on their own standard. It would be nice to converge on a single standard, that also supports private groups.
• URL handlers. Again, competing standards: FediLinks, FEP-07d7 and several other proposals.
• Quoting. FEP-e232 is a proposed standard, but most fediverse applications still use non-standard properties. Mastodon developers are trying to invent something completely different.
• Synchronization of replies. Various approaches are being considered, but there's no clear winner.
• Markets. So far there's only one server implementation capable of processing payments. FEP-0837 (a protocol for federated marketplace) was designed, but lacking adoption.
• Forge federation. ForgeFed is being implemented in Forgejo, although the work is progressing very slowly.

silverpill, 2 months ago to random

Decentralized identifiers (DIDs) can be divided into 3 categories, depending on where the authority resides:

• Secret key (did:key, did:pkh).
• Server (did:web).
• Blockchain (hundreds of them).

With a #DID derived from a secret key you can truly own your identity. Unfortunately, key rotation is not supported, and if you lose your key, you lose everything. This can be partially mitigated with distributed key generation techniques that make key recovery possible if only M of N shards are available, but they are complicated.

Servers can rotate keys, but they can also suddenly disappear, and again you lose everything.

Blockchain-based systems support key rotation and don't have a single point of failure (if done right). Sometimes they are called "servers with superpowers". However, popular ones are not suitable for the job because writing to them is very expensive and their clients need powerful computing devices and a lot of storage.

Is there a way around that? Yes. Blockchains can be very lightweight and they don't actually need a cryptocurrency, miners or stakers in order to work. There is a simple consensus algorithm known as Proof of authority, and one of the Fediverse competitors, Bluesky, seems to be planning to build such system:

https://github.com/did-method-plc/did-method-plc

>We are actively hoping to replace it with or evolve it into something less centralized - likely a permissioned DID consortium.

They are afraid to say the B-word, but "permissioned consortium" is exactly what it is. Of course, their identity #blockchain doesn't have to be the only one in existence. I think in the future we might see quite a lot of "identity cooperatives" of different shapes and sizes. Perhaps even a universal client, curl for identity, can be developed.

silverpill, 9 months ago to random

https://mastodon.social/users/torproject/statuses/110906828593942566

@torproject announced they will participate in Gitcoin funding round and everyone immediately started attacking them, saying it's a scam, and telling them that they don't need the money (lol).

Well, Gitcoin is basically a crowdfunding platform. It's definitely not a scam, and I know many FOSS projects that used it. Also, Gitcoin is actually interesting because they use an innovative donation matching mechanism called Quadratic Funding (see https://www.wtfisqf.com).

There's nothing wrong with Tor Project using this platform to raise more money. Trying to prevent them from doing so is absolutely insane, and this is what brainwashing by "web3 is going just great" does to you. This account is slandering good projects while constantly promoting actual scams which no one would ever heard of otherwise.

silverpill, 6 months ago (edited 6 months ago) to fediverse

I think FEP-ae97 with server-independent IDs is the best way to make identities and data portable in #ActivityPub world.

FEP-c390 + Move activity makes identity portable but not data, and requires wide adoption to provide meaningful benefits. So far there haven't been much interest from developers.

FEP-ae97 with server-independent IDs makes data portable as well, and while it is not compatible with existing software, the server can support both AP flavors at the same time, so it is not worse than FEP-c390 + Move. I also found a way to make it work with Mastodon API, that makes it a clear winner.

There is still a couple of things that need to be figured out, of course:

• What is the best way to specify a list of hosts where data is stored? I'm not entirely satisfied with ?hosts=server1.example,server2.example solution.
• How to encrypt data? It's harder to maintain confidentiality of private messages when they are stored on multiple servers, therefore they should be encrypted.

silverpill, 11 months ago to random

My plan for nomadic identity / SSO:

https://codeberg.org/silverpill/mitra/issues/43

did:onion seems to be the best option. Not ideal, but DIDs are composable, and new methods can be supported with little effort.

silverpill, 9 months ago to random

https://github.com/cloudflare/wildebeest

Cloudflare didn't make it

>This project has been archived and is no longer actively maintained or supported

silverpill, 6 months ago to random

So, a decentralized alternative to Bandcamp is needed?

In theory musicians can use Mitra to release music to paid subscribers. I can also implement a paywall mechanism that works on individual posts.

https://timetheft.social/users/jazz/statuses/111296776010291428

silverpill, 4 months ago to random

Activity Connect, my little side-project, has reached usable state:

https://codeberg.org/silverpill/activity-connect

• Follow, unfollow, create and delete posts - basic activities are supported. Translation is not perfect but can be improved in the future.
• Allowlist-based bridging
• Tor and I2P are supported
• Media URLs are not translated
• Compiled to a single binary, uses SQLite database, configured with environment variables

silverpill, 1 month ago to random

https://matrix.org/blog/2024/04/open-source-publicly-funded-service/

>FOSS maintenance should be funded by governments on behalf of the taxpayer

Matrix people are struggling to maintain their tech and they are begging governments to take money from YOU to help them stay afloat.

Let them sink. We already have XMPP, and E2EE over AP is also coming.

silverpill, 4 months ago to random

#Mitra v2.6.0

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

This release contains many small improvements, including federation with Discourse, support for Phanpy client and automatic media cleanup after profile updates

silverpill, 2 months ago to random

It's official now: Threads implemented FEP-e232

https://engineering.fb.com/2024/03/21/networking-traffic/threads-has-entered-the-fediverse/

Article contains a couple of minor inaccuracies: _misskey_quote doesn't build on FEP-e232, and the other property name is quoteUrl, not quoteURL. But overall it's good and I hope other implementers will notice it.

#FEP

silverpill, 10 months ago to random

Working on a protocol specification for federated marketplace

https://codeberg.org/silverpill/feps/src/branch/main/0837/fep-0837.md

silverpill, 6 months ago to random

#Mitra v2.3.0

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

Highlights:

• Implemented replies collection. This means replies to Mitra posts can be fetched using mitractl fetch-replies command. Eventually this feature (loading missing replies) will be available in the GUI too.
• Profile images can be removed.
• Donation buttons for Lightning Network addresses (Mitra is looking for profile fields with labels "lightning address" and "lud16", just like PeerTube Lightning plugin).
• (Experimental) Support for recurrent payments via Monero Subscriptions Wallet. I haven't tried the app yet, just added automatic generation of their payment request codes for every invoice.

silverpill, 8 months ago to random

#Mitra v1.34.0
https://codeberg.org/silverpill/mitra/releases/tag/v1.34.0
https://codeberg.org/silverpill/mitra-web/releases/tag/v1.34.0

Implemented "locked" accounts and follow request management.

silverpill, 7 months ago to random

#Mitra v2.2.0

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

Implemented post editing

silverpill, 1 year ago to random

Keys vs passwords. Pretty good article on the subject:

https://open.substack.com/pub/subconscious/p/trustless-protocols-are-better-than

>You can always implement key custody on top of user-owned keys. If you want key custody, you can have key custody. If you want a cold wallet, you can have a cold wallet. Trustful protocols bake assumptions about authority directly into the infrastructure. Trustless protocols give you the choice.

The great thing about Fediverse is that we can have both traditional identities and identities based on keys.

silverpill, 1 year ago to random

Testing FEP-e232.

This is a quote post. Pleroma users won't see it, but Akkoma, Rebased and other servers should be able to process it.

https://w3c.social/users/w3c/statuses/110231338432824087

silverpill, 5 months ago to random

Important information for FEP-8b32 and FEP-c390 implementers:
https://github.com/w3c/vc-data-integrity/issues/231

It was reported that context injection is a necessary step for eddsa-jcs-2022 cryptosuite. It is necessary even if secured object is nested inside an object with @context property (as in FEP-c390).

This means FEP-c390 feature file is wrong, because I assumed that context injection is not needed. What's worse, it is not even clear how context injection must be done in this case (should we inject a string, or an array?).

In cases where top-level object is being signed, the context injection is not needed, so existing FEP-8b32 implementations are probably correct.

silverpill, 15 days ago to article_interop

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

silverpill, 6 months ago to random

My actor passes all tests at https://verify.funfedi.dev

https://verify.funfedi.dev/?actor_uri=https%3A%2F%2Fmitra.social%2Fusers%2Fsilverpill

silverpill, 4 months ago to random

New version of Friendica is out, and it includes a fix for federating with Mitra

https://forum.friendi.ca/objects/39bbe52a-9613b739-9b7018b2d7b1488f

silverpill, 5 months ago to random

More Instant Messaging Interoperability (MIMI)

https://datatracker.ietf.org/doc/draft-barnes-mimi-arch/

The architecture document describes a federated system (with clients and servers), so it is a good starting point for designing E2EE in Fediverse. The architecture also seems to be compatible with FEP-e61.

MIMI specifies its own message format, which we probably don't need because we already have one. However, it might be a good idea to borrow some parts from this spec, as there are similarities between it and AP

>This proposal relies on URIs for naming and identifiers

silverpill, 1 month ago to random

https://activitypub.ghost.org/

Who's next? Substack? Twitter?

silverpill, 6 months ago to random

https://pleroma.social/announcements/2023/10/29/pleroma-release-2.6.0/

Finally!

This release includes fixes for bugs that prevented adoption of FEP-e232 and FEP-fffd

silverpill, 7 months ago to fediverse

Authentication/Authorization page in #ActivityPub wiki has been brought up to date:

https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization