Email or username:

Password:

Forgot your password?
silverpill's posts Back to profile
211 posts total
silverpill

NIST: Transition to Post-Quantum Cryptography Standards

https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf

ECDSA, EdDSA and RSA will be disallowed after 2035 (page 20)

20 December at 14:57 | Open on mitra.social
silverpill
fedicat
20 December at 7:34

adding support in #Fedicat for the Conversation post visibility in #Mitra

screenshot of a timeline with the top post listing Conversation as its visibility Detected text: 12:29Homeexampletechnicats• Conversationtechnicattechnicat@technicat test reply from mitra@technicat@universeodon.com12:28 AM& shy (visible to followers)technicattechnicat@universeodon.comtest post for mitra12:28 AMtechnicatscliquish (visible to mentioned)technicattechnicat@technicat ilkj;lkj;lkj@technicat@universeodon.com12:26 AMtechnicats@ cliquish (visible to mentioned)tachnicat12:26 AM
20 December at 11:39 | Open on mitra.social
silverpill
@reiver ⊼ (Charles) :batman:
18 December at 15:36

📚 Mastodon History

Back in February 23rd, 2016 — Mastodon first described itself as:

“Mastodon is a federated microblogging engine. An alternative implementation of the GNU Social project.”

The history of Mastodon is tied to GNU Social.

github.com/mastodon/mastodon/b

github.com/mastodon/mastodon/t

#DeSo #Fediverse #FediverseHIstory #GNUSocial #Mastodon #MastodonHistory

Mastodon Mastodon is a federated microblogging engine. An alternative implementation of the GNU Social project. Based on ActivityStreams, Webfinger, PubsubHubbub and Salmon. The core ideals of this project are: • Independence of legacy Twitter APIs - we don't want to be compatible with Twitter clients, we want our own clients • In that vein, a strong and clean REST API and OAuth2 • Minimalism. Just because you can do almost anything with ActivityStreams doesn't mean you should. Limit the set of possible functions to what makes sense in a microblogging engine. This will make federation as well as UI design a lot easier • Ease of deployment. The end-goal of this project is to be distributable as a Docker image. Current status of the project is early development. Documentation, licensing information &co will be added later
19 December at 0:35 | Open on mitra.social
silverpill
チャノさん@C102、日曜日東ピ24a
16 December at 14:33

Work is still incomplete, but this is the new cover design for the upcoming JP Mitra install guide doujin (with Shadow Wizards courtesy of @ehhh ).

The completed book will be debuted in Onionket 8 next February, and then God willing the physical version will be printed for Summer Comiket C106 in August after that.

cc @silverpill
16 December at 19:51 | Open on mitra.social
silverpill
Erlend Sogge Heggen
15 December at 20:47 on post We would like to run an #activitypub instance as part of the #weirdone platform, same as the excellent...

The instance type we’d like to host is most likely gonna be @mitra #mitra

..specifically because it supports nomadic identity, so neither our instance nor our users are locked in stasis; Weird net can migrate to a different AP instance in the future if necessary, and instance tenants can migrate to any other instance that supports Nomadic Identity (FEP-ae97), e.g. with:

codeberg.org/silverpill/fep-ae

It’s pretty easy to self-host; the real challenge is instance governance and moderation.

The instance type we’d like to host is most likely gonna be @mitra #mitra

..specifically because it supports nomadic identity, so neither our instance nor our users are locked in stasis; Weird net can migrate to a different AP instance in the future if necessary, and instance tenants can migrate to any other instance that supports Nomadic Identity (FEP-ae97), e.g. with:

16 December at 19:35 | Open on mitra.social
silverpill

>sub.club is shutting down

But #mitra is not.

And if you really want to use Stripe, we can try to find a way to make it work:

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

RE: https://mastodon.social/users/subclub/statuses/113646793698065585

13 December at 18:47 | Open on mitra.social
silverpill
Helge
11 December at 8:03

Good morning Fediverse. It's a gray day.

In case, you need reading material, I wrote FEP-1311: Media Attachments.

Note: Codeberg is down right now. It's not my fault by posting this link. It also was before.

12 December at 0:05 | Open on mitra.social
silverpill
Nomad
9 December at 12:20

Nomad Protocol and Nomadic Identity in the Fediverse

A New Home Page for Nomad Protocol

I just created a new home page for the Nomad Protocol website. It explains, in simple terms, what the Nomad Protocol is and why it exists. It also touches upon Nomadic Identity and efforts to port that over the ActivityPub.

Nomad Protocol and Nomadic Identity in the Fediverse

#^https://opennomad.net/page/nomad/home

Nomad Protocol and Nomadic Identity in the Fediverse

A New Home Page for Nomad Protocol

I just created a new home page for the Nomad Protocol website. It explains, in simple terms, what the Nomad Protocol is and why it exists. It also touches upon Nomadic Identity and efforts to port that over the ActivityPub.
9 December at 18:33 | Open on mitra.social
silverpill
silverpill

Iceshrimp.NET has a section titled "FEPs we intend to support in the future" in their FEDERATION.md:

https://iceshrimp.dev/iceshrimp/Iceshrimp.NET/src/branch/dev/FEDERATION.md#feps-we-intend-to-support-in-the-future

Streams: "Fediverse FEPs we will not ever support"

https://codeberg.org/streams/streams/src/branch/release/FEDERATION.md#fediverse-feps-we-will-not-ever-support

NodeBB has a similar page in their documentation where position towards various FEPs is indicated using words "positive", "neutral", "defer", and "negative":

https://docs.nodebb.org/activitypub/fep/

I think this is a good practice.

Iceshrimp.NET has a section titled "FEPs we intend to support in the future" in their FEDERATION.md:

https://iceshrimp.dev/iceshrimp/Iceshrimp.NET/src/branch/dev/FEDERATION.md#feps-we-intend-to-support-in-the-future

Streams: "Fediverse FEPs we will not ever support"

https://codeberg.org/streams/streams/src/branch/release/FEDERATION.md#fediverse-feps-we-will-not-ever-support

7 December at 21:03 | Open on mitra.social
silverpill

Today, on the anniversary of publishing FEP-ef61, nomadic actors on Streams and Mitra made their first contact.

I created a signed Follow activity using the nomadic client and sent it to the Mitra gateway, which delivered activity to a nomadic actor on the Streams server. The Streams actor sent an Accept activity back, which I then picked from my inbox on the gateway.

#fep_ef61 #NomadicIdentity

6 December at 21:03 | Open on mitra.social
silverpill

FEP-67ff: FEDERATION.md has been finalized.

It is now supported by 17 Fediverse projects!

#fep

6 December at 18:22 | Open on mitra.social
silverpill
Helge
6 December at 7:46

Good morning Fediverse. It's storming and raining.

I just realized that I'm running out of time to start something on my todo list. The prototype fund has a funding round with deadline January 2nd, 2025.

An interesting infrastructure problem to tackle would be Fediverse media server. I'll leave the technical discussion aside.

Question:

- Are there German instance owner, that would be interested in helping test/run/develop such a solution?
- Would you be willing to help write a proposal?
- Would you be willing to set up an entity to help run a media server collective long term?

Good morning Fediverse. It's storming and raining.

I just realized that I'm running out of time to start something on my todo list. The prototype fund has a funding round with deadline January 2nd, 2025.

An interesting infrastructure problem to tackle would be Fediverse media server. I'll leave the technical discussion aside.

6 December at 16:53 | Open on mitra.social
silverpill

FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/455

I added a couple of sentences clarifying FEP-ef61 design goals. In particular:

1. "This document describes web gateways, which use HTTP transport. However, the data model and authentication mechanism are transport-agnostic and other types of gateways could exist."

FEP-ef61 is designed to be compatible with any transport protocol, including the sneakernet. For example, it should be possible to replace web gateways with iroh nodes.

2. Location discovery using DID services. It came to my attention that some developers are trying to implement a variation of FEP-ef61 where gateways are specified in a DID document instead of an actor document. That significantly differs from existing FEP-ef61 implementations (Streams and Mitra), and has a serious practical disadvantage: it doesn't work with generative DID methods such as did:key. Support for pure key-based identities is important for several reasons:

- It is very useful for client-to-client (#p2p) communication without servers.
- Interoperability with other protocols that use public keys as identities. #Nostr is probably the most popular, but there are many more.
- It lowers the barriers to entry for client developers, who otherwise would need to deploy a did:web or something more complicated like did:webvh.

So, don't do that.

Also added a discussion section about media access control.

If media identifier only contains a digest, the gateway can't restrict access to it. This may not be a big problem because digest is very hard to guess, but an access control mechanism still might be useful. One way to implement it is to add an 'ap' identifier of a parent document to a hashlink and make it mandatory.

#fep_ef61 #NomadicIdentity #DataPortability

FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/455

I added a couple of sentences clarifying FEP-ef61 design goals. In particular:

1. "This document describes web gateways, which use HTTP transport. However, the data model and authentication mechanism are transport-agnostic and other types of gateways could exist."

6 December at 1:18 | Open on mitra.social
silverpill
Justin Thomas 🛡
5 December at 19:14

I finally began documenting the #E2EE cryptosystem I'm implementing in #Enigmatick

gitlab.com/enigmatick/enigmati

Even though my implementation in Enigmatick is still a work-in-progress, I think I've settled on the big details enough that I can begin documenting the ideas. And my implementation is less important than getting the core ideas out there for thought and discussion.

Please use this issue for comments:

gitlab.com/enigmatick/enigmati

I finally began documenting the #E2EE cryptosystem I'm implementing in #Enigmatick

gitlab.com/enigmatick/enigmati

Even though my implementation in Enigmatick is still a work-in-progress, I think I've settled on the big details enough that I can begin documenting the ideas. And my implementation is less important than getting the core ideas out there for thought and discussion.

5 December at 20:22 | Open on mitra.social
silverpill

@justin Am I understanding it correctly that client's secret keys are client-side encrypted and stored on the server (as olm accounts)? If so, which key is used for encryption?

Do clients sync their keys using those server-side encrypted accounts?

5 December at 20:28 | Open on mitra.social
silverpill

FEP-171b update: https://codeberg.org/fediverse/fep/pulls/454

Some clarifications, and an explanation of why FEP-fe34 authentication is important:

>The processing of unauthenticated embedded activities is strongly discouraged. If such activities are not rejected by the consumer, a malicious conversation owner may be able to perform a cache poisoning attack and overwrite any actor or a post in consumer's local cache by sending a forged Update(Actor) or Update(Object) wrapped in an Add activity.

This is not difficult to do. Someone makes a post and says "hey everyone, join my new @group about <popular_topic>". People join and the next day Gargron is messaging them and asking to fund Mastodon's new Trust & Safety initiative by donating bitcoins.

Similar attacks might be possible against FEP-1b12 implementations that don't authenticate announced activities.

#fep_171b #ConversationContainers #ActivityPub

FEP-171b update: https://codeberg.org/fediverse/fep/pulls/454

Some clarifications, and an explanation of why FEP-fe34 authentication is important:

>The processing of unauthenticated embedded activities is strongly discouraged. If such activities are not rejected by the consumer, a malicious conversation owner may be able to perform a cache poisoning attack and overwrite any actor or a post in consumer's local cache by sending a forged Update(Actor) or Update(Object) wrapped in an Add activity.

5 December at 19:57 | Open on mitra.social
silverpill
Helge
5 December at 7:52

Good morning Fediverse. It's a sunny day with a blue sky.

I've finally finished a first version: Recommended Media Attachment Format. My recommended format includes more properties than any current Fediverse application provides.

There are still a lot of work items, e.g. where did akkoma go? Or to write a FEP explaining how these properties are useful. However, I think that if we start working towards using these examples as a model for how to implement media attachments than whatever we can find in ActivityPub, we will make the Fediverse a better place. It will be a long road to there.

Good morning Fediverse. It's a sunny day with a blue sky.

I've finally finished a first version: Recommended Media Attachment Format. My recommended format includes more properties than any current Fediverse application provides.

There are still a lot of work items, e.g. where did akkoma go? Or to write a FEP explaining how these properties are useful. However, I think that if we start working towards using these examples as a model for how to implement media attachments than whatever we can find...

5 December at 10:38 | Open on mitra.social
silverpill
marius
4 December at 16:02

I've finally got off my ass and created a Codeberg account in order to submit my first PR to the #FEP repository.

I'm not very familiar with the FEP submission etiquette so any pointers from more experienced people would be helpful.

The PR: codeberg.org/fediverse/fep/pul

Mailing list thread for feedback: lists.sr.ht/~mariusor/go-activ

#activitypub #activitypubdev

4 December at 23:30 | Open on mitra.social
silverpill
Helge
3 December at 8:00

Good morning Fediverse. The sky is gray and so are my thoughts.

Anyway, this post by @silverpill triggered me to look at media attachments in the Fediverse again 😭😭😭

This resulted in inputs#48 and a general state of despair. The situation could be nice. One could provide a recommendation on how to do media attachments. They could include stuff like the width and height of an image, that has been broken and reported in ActivityStreams for over 5 years. One could include a file size and digest, because one cares about bandwidth and integrity (ActivityStreams doesn't).

Instead one gets this and that. I'm not going to detail everything wrong about this. 🤷‍♂️ It would take more time than writing a proper specification document.

If you have opinions, in particular on the digest format and what to use to represent file size, please comment. A note on digest. digestMultibase seems like a footgun to me due to the inclusion of the length byte. Not sure if there is something better.

Good morning Fediverse. The sky is gray and so are my thoughts.

Anyway, this post by @silverpill triggered me to look at media attachments in the Fediverse again 😭😭😭

This resulted in inputs#48 and a general state of despair. The situation could be nice. One could provide a recommendation on how to do media attachments. They could include stuff like the width and height of an image, that has been broken and reported in ActivityStreams for over 5 years. One could include a file size and digest,...

3 December at 21:36 | Open on mitra.social
silverpill

@helge An alternative to digestMultibase is digestSRI (mentioned in VC spec), but digestMultibase seems to be more popular among VCDI spec authors and unlike digestSRI, it is now in security context.

Regarding width, height, digest and others: perhaps these properties should be added to url? One image may have multiple representations, for example low res and high res. IIRC PeerTube provides videos in multiple variants and has a long array of links in url.

{
  "type": "Image",
  "url": [{
    "type": "Link",
    "href": "https://example.social/image.png"
    "height": 2000,
    "width": 2000,
    "digestMultibase": "zQm1"
  }, {
    "type": "Link",
    "href": "https://example.social/image_thumbnail.png",
    "height": 100,
    "width": 100,
    "rel": "https://example.social/ns/thumbnail",
    "digestMultibase": "zQm2",  <- different digest!
 }]
}

@helge An alternative to digestMultibase is digestSRI (mentioned in VC spec), but digestMultibase seems to be more popular among VCDI spec authors and unlike digestSRI, it is now in security context.

Regarding width, height, digest and others: perhaps these properties should be added to url? One image may have multiple representations, for example low res and high res. IIRC PeerTube provides videos in multiple variants and has a long array of links in url.

3 December at 22:05 | Open on mitra.social
silverpill

Testing attachment with digestMultibase
1 December at 15:37 | Open on mitra.social
Go Up