Notices by silverpill (silverpill@mitra.social), page 27

@mikedev @smallcircles @steve @zicklag
Yes, it would be more correct to compare HTML with ActivityStreams. I just tend to think of AS and AP as a single standard.

@japananon Yes, it is needed when building from source. Deb packages only depend on postgresql

@greyarea I'm trying to support software versions provided by Debian stable. Except for Rust, for which the policy is "not newer than version in Debian testing" (the Rust ecosystem is still rapidly evolving and unfortunately compiler versions older than 1 year are considered outdated even by maintainers of libraries)

Version 3.0 is coming. #Mitra uses semantic versioning: major version increase indicates breaking changes. Normally, upgrades are easy, you just need to replace binaries and restart the service, but major release will likely require additional interventions.

The most notable change in Mitra 3.0 is an increase of minimum required versions of software dependencies:

- PostgreSQL 15
- Rust 1.75
- NodeJS 18 (for Mitra Web)

There will also be changes related to the configuration file and changes in federation protocol that will make Mitra incompatible with very old versions of itself (<2.0.5). Finally, I'm removing the Ethereum payment processor that has been in low maintenance mode for a long time. (#Monero is still supported, and there are no plans to remove it. People are actually using it.)

The full list of planned changes can be found here: https://codeberg.org/silverpill/mitra/issues/68

@knt

The verbosity of a log can be controlled with a RUST_LOG environment variable. For example, to hide INFO messages:

But I can add --debug (or --log-level) parameter too.

@knt How do you think, should log messages be hidden by default in mitractl output?
I've got used to them, but I imagine that other operators might perceive these messages as noise

@julian

Unrelated: the Announce activity sent by your server has wrong ID, it pretends that activity belongs to my server

https://mitra.social/objects/0190c6ee-69fc-59ae-d415-77b1f5e4c5f1#activity/announce/1721324460712

@julian

>and serve them using the common ETag header

Nice. Does it eliminate the need for a custom Collection-Synchronization header?

(initially replied from SocialHub but my reply didn't federate)

@waifu Picked a wrong instance (a common mistake).

@steve @smallcircles @zicklag ActivityPub is underspecified in the same way HTML is underspecified. It's a feature, not a bug.

The spec can be improved, of course, but I don't think it is a sketch.

@zicklag @smallcircles

Makes sense.

I'm not familiar with iroh but if it supports mutable data pointers (in contrast to immutable pointers like CIDs in IPFS), it should be possible to use iroh together with FEP-ef61 flavor of ActivityPub.

@zicklag @smallcircles

>But ActivityPub is also largely underspecified

ActivityPub is not underspecified. Developers might get frustrated when they read the spec and discover that it doesn't explain how to communicate with Mastodon. But this is only because the scope of the spec is much broader. It is a protocol for building all kinds of decentralized social applications, and some of them can be quite different from micro-blogging services.

>We prefer to make a very precise protocol specification to give tight interoperability at it's core, but allow component data and schemas to develop independently for extension.

You can create an interop profile for ActivityPub which can be as precise as you want. It can be very strict and at the same time compatible with many existing applications (best practices for interop has been already discovered, and the work on formalizing them is ongoing).

Extensibility is baked in (ActivityPub is a culmination of several decades of experimentation with semantic web concepts).

Of course, you can design a different protocol, but bootstrapping protocols is a very difficult task. #ActivityPub is already popular, and it has all the properties of the Web of Data you've described in your post.

>That said, interoperability with ActivityPub is something we are very interested in.

Interoperability can be achieved by adopting ActivityPub data model (ActivityStreams 2.0). A common language will enable communication without centralized bridges. Transport protocols are secondary

@zicklag ActivityPub IDs are URIs, and URIs don't always require DNS or servers. That depends on URI scheme.

One AP-compatible URI scheme with key-based naming authority is described in FEP-ef61. This FEP discusses HTTP transport, but the object format is designed to be transport agnostic. It is suitable for local-first applications too

@smallcircles

@zicklag @smallcircles

>Imagine an alternative internet protocol were each “thing” on the internet is an “Entity”. Entities might represent blog articles, chat messages, tweets, comments, or anything else. Each entity also has a path to that entity, like a URL.

This protocol is called "ActivityPub". Objects are entities, their IDs are paths, and their properties are components.

https://www.w3.org/TR/activitypub/

@pfefferle the-federation.info has been broken for a while... But surprisingly, Fediverse Observer also seems to be wrong because it only displays 177 instances:

https://wordpress.fediverse.observer/list

FediList has 7933, which is more plausible:

http://demo.fedilist.com/instance?software=wordpress

Matrix/Element is broken again

https://github.com/element-hq/element-web/issues/27682

and it can't be fixed because of "policy". What a horrible mess

@onionket_staff It would be nice to submit it to the Umbrel app store

https://apps.umbrel.com/

Umbrel was originally focused on Bitcoin, but recently they added Monero node, and there is a plenty of non-crypto stuff too

@onionket_staff @knt I suspect that Monero integration is not a part of the package. A Mitra instance that processes Monero payments might be viewed by authorities as a money transmitting service, and many hosting providers would prefer to avoid that.

@frogzone Mitra can't do that at the moment. But it shouldn't be difficult to implement, I'll look into it.

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

No breaking changes this time, this PR mostly contains clarifications based on our implementation experience. Streams and Mitra has been added to the implementation list.

#fep_ef61