Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
social.tchncs.de is one of the many independent Mastodon servers you can use to participate in the fediverse.
A friendly server from Germany – which tends to attract techy people, but welcomes everybody. This is one of the oldest Mastodon instances.

Administered by:

Server stats:

3.8K
active users

social.tchncs.de: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#fep_ef61

0 posts0 participants0 posts today
Public
silverpill

FEP-ef61 "Portable Objects" update:

https://codeberg.org/fediverse/fep/pulls/529

The role of decentralized identifiers in FEP-ef61 is similar to "servers" in vanilla ActivityPub: they control all actors within a certain namespace.
When multiple actors exist under DID's authority, they will likely use same gateways. I added a sentence saying that gateways can be advertised via DID document as DID services (an example of that can be found in did:fedi spec). This is not possible with did:key, but might be useful with other DID methods.
I am also considering moving gateways property to actor's endpoints mapping, where server-wide endpoints such as sharedInbox are usually defined (in our case they are "DID-wide").

Forgejo: Beyond coding. We Forge.FEP-ef61: Endpoints and services- Added `endpoints.gateways` to the list of `gateways` alternatives. - Specified optional publishing of gateways as DID sarvices. - Added note about ActivityPub compatibility. - Added warning about changing URI scheme. - Added `type` to proposal metadata. - Changed "Controller Documents" to ...
#fep_ef61#NomadicIdentity
Public
silverpill

I updated "Authentication and authorization" section of FEP-ef61 (Portable objects): https://codeberg.org/fediverse/fep/pulls/497.

Authentication requirements in FEP-ef61 differ depending on the object class. Actors, activities and objects must always be signed (i.e. have an integrity proof). Signing collections may be impractical, so we make an exception for them, and trust the gateway if that gateway is trusted by actor. Links are not supposed to have an id, and there is no requirement to sign them.

This would not be possible without FEP-2277 which provides a classification of ActivityPub objects based on their shape.

FEP-2277 also got a small update. The algorithm now gives Link a higher priority: https://codeberg.org/fediverse/fep/pulls/496

Codeberg.orgFEP-ef61: Rewrite "Authentication and authorization" sectionClarifying how different classes of objects are authenticated (based on [FEP-2277](https://codeberg.org/fediverse/fep/src/branch/main/fep/2277/fep-2277.md) classification).
#fep_ef61
Public
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.

Summary card of repository fediverse/fep
Codeberg.orgfep/fep/ef61/fep-ef61.md at mainfep - Fediverse Enhancement Proposals
#fep_ef61#NomadicIdentity
Public
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.

Codeberg.orgFEP-ef61: Update proposal- Updated "History". - Replaced did:tdw with did:webvh. - Added a note about non-web gateways. - Describe location discovery using DID services. - Clarified how gateways with arbitrary paths can work. - Added a section about media access control.
#fep_ef61#NomadicIdentity#DataPortability
Continued thread
Public
silverpill

Access control would require additional information to be encoded in hashlink URI (in its metadata component). I think it should be the 'ap' ID of the containing object. Perhaps it should be even mandatory, because there is no good reason to store random files on a FEP-ef61 gateway.

IETF DatatrackerCryptographic HyperlinksWhen using a hyperlink to fetch a resource from the Internet, it is often useful to know if the resource has changed since the data was published. Cryptographic hashes, such as SHA-256, are often used to determine if published data has changed in unexpected ways. Due to the nature of most hyperlinks, the cryptographic hash is often published separately from the link itself. This specification describes a data model and serialization formats for expressing cryptographically protected hyperlinks. The mechanisms described in the document enables a system to publish a hyperlink in a way that empowers a consuming application to determine if the resource associated with the hyperlink has changed in unexpected ways.
#fep_ef61
Public
silverpill

FEP-ef61 update: I've added a description of integrity protection mechanism for media.

https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#media

It is now recommended to add digestMultibase property to objects representing images and other external resources, and hashlinks are recommended for references (because they are also based on multihashes).

Adding digestMultibase is a good idea even if object is not portable. That allows recipients to verify integrity of a file when it is served by a 3rd party, and makes it possible for them do skip download if they already have a copy.

Summary card of repository fediverse/fep
Codeberg.orgfep/fep/ef61/fep-ef61.md at mainfep - Fediverse Enhancement Proposals
#fep_ef61
Replied in thread
Public
Jupiter Rowland
@Jenniferplusplus I sincerely hope that you aren't building Letterbook to only interact with itself and Mastodon.

Sooner or later, Letterbook will encounter content coming in from instances of software created by @Mike Macgirvin ?️, namely Friendica, Hubzilla (these two are actually older than Mastodon), (streams) or Forte. For reference: I am on Hubzilla.

You/it will have to expect and be able to deal with the following:
  • Enclosed one-post-many-comments conversations instead of threads that consist of posts loosely tied together
  • Permissions of all comments/replies firmly defined by the start post; permissions/visibility can't be changed within a running conversation
  • "Monster posts" of any length because none of them has a character limit
  • Not just Note-type objects, but also Article-type objects (from Friendica right now, the others may implement them once Mastodon introduces sensible support for them)
  • Full HTML text formatting, up to and including numbered lists, tables, horizontal lines, character size and character colour
  • Both quotes (as done in bulletin-board forums) and quote-posts (posts fully embedded in other posts like quote-tweets)
  • Embedded links (this comment makes a whole lot of use of them)
  • Inline images embedded within the text, and more than four of these in one post
  • Inline audio streams embedded within the text
  • Inline videos embedded within the text
  • "Weird" mentions and hashtags with the @ or the # not part of the link (look at the mentions and the hashtags in this comment, then look at mentions and hashtags on Mastodon and compare them)
  • "Summaries in the CW field" (because Mastodon repurposed StatusNet's summary field, which was used by StatusNet, Friendica and Hubzilla as an actual summary field, for content warnings in 2017; several Fediverse server apps continue to use it for summaries)
  • All four support titles in addition to summaries

Some of the above may also come in from elsewhere, e.g. a wider range of text formatting than Mastodon allows itself to render is fully supported by just about everything that isn't Mastodon.

Also, ActivityPub is currently evolving. New FEPs are being put to use and bringing in new features far away from how Mastodon is working. In particular, (streams) and Forte and @silverpill's Mitra use decentralised identifiers as per FEP-ef61 (Portable Objects). Forte has nomadic identity fully implemented via ActivityPub while (streams) at least supports it. And all three have conversation containers implemented, silverpill wants to make them an FEP, and Hubzilla is planning to implement them with version 10.

This means three things. One, weird identifiers. Two, weird actor identities: What looks like one user automatically cross-posting to another account on another instance to non-nomadic ActivityPub implementations is actually the very same actor residing simultaneously on multiple server instances. Three, again, conversations work drastically different from Twitter and Mastodon.

Lastly, it may be a good idea to implement a little server type display from the get-go so that the user knows what kind of Fediverse instance something comes from. Misskey and its forks have it, Friendica has it, (streams) has it, Forte has it. Just because Mastodon doesn't have it, doesn't mean it's a good idea not to have it. Besides, if content from certain server applications malfunctions on Letterbook, users can pinpoint right away what server application causes that trouble when submitting a bug report.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #Conversations #ConversationContainers #FEP_ef61 #NomadicIdentity
joinfediverse.wikiWhat is Friendica? - Join the Fediverse
#nomadicidentity
Replied in thread
Public
Jupiter Rowland
@Strypey A few more details:

* FEP-ef61: Portable Objects

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

Invented in, I think, 2023 by @silverpill for Mitra (based on ActivityPub). Currently implemented there and in @Mike Macgirvin ?️'s streams repository and Forte. Part of the plan to introduce almost Nomad-level, but cross-project nomadic identity to ActivityPub.

* FEP-61cf: The OpenWebAuth Protocol

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

Invented in 2018 by Mike Macgirvin for Zap (Zot6 development platform; discontinued 2022). Backported to Hubzilla in 2020. Full server-side and client-side implementation only in Hubzilla (based on Zot6, also supports ActivityPub etc.), (streams) (based on Nomad, also supports Zot6 and ActivityPub) and Forte (based on ActivityPub). Friendica has a client-side implementation. Mastodon has a client-side implementation pull request that has to be merged eventually.

CC: @Laurens Hof

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Friendica #Hubzilla #Zap #Streams #(streams) #Forte #Zot #Zot6 #Nomad #ActivityPub #FEP #FEP_ef61 #FEP_61cf #DecentralizedIdentity #NomadicIdentity #OpenWebAuth #SingleSignOn
Mastodon - NZOSSStrypey (@strypey@mastodon.nzoss.nz)39.7K Posts, 2.99K Following, 3K Followers · Free human being of this Earth. Pākeha in Aotearoa. Be excellent to each other! Matrix: @strypey:matrix.iridescent.nz All my posts here are CC BY-SA 4.0 (or later). #Vegan #Permaculture #PeerProduction #SoftwareFreedom #PlatformCooperatives #FreeCode #CreativeCommons #SciFi #Comedy #Juggling #fedi22
#singlesignon
Public
silverpill

'ap' URLs are not valid URIs according to RFC-3986. FEP-ef61 describes a possible solution: percent-encode a DID (the authority component of an 'ap' URL)

Today I found another solution. RFC-3986 allows future, as-yet-undefined IP literal address formats if they are enclosed in square brackets and prefixed with a version flag.

For example, this is a valid URI:

ap://[vd.did:key:z6MkvUie7gDQugJmyDQQPhMCCBfKJo7aGvzQYF2BqvFvdwx6]/objects/123
#fep_ef61
Replied in thread
Public
Jupiter Rowland
@glyn Decentralised identity has been available for longer than Mastodon, let alone ActivityPub. Only that it is known as "nomadic identity" here.

It was first implemented by Friendica creator @Mike Macgirvin ?️ in the Zot protocol in 2011 and in a Friendica fork named Red in 2012, later renamed into the Red Matrix, eventually reworked and renamed into Hubzilla in 2015.

Proof: This Hubzilla channel of mine actually simultaneously resides on two servers.

(Almost) everything that Mike has made afterwards, forks and forks of forks of Hubzilla, used to have or still have nomadic identity implemented.

His streams repository contains a fork of a fork... of Hubzilla that intentionally has no name, and that offers nomadic identity via the Nomad protocol with better compatibility with non-nomadic ActivityPub. In July, it had decentralised IDs as per FEP-ef61 (see also here) implemented, a first step by Mike to fully implement nomadic identity in ActivityPub.

Forte, Mike's most recent fork from August, had all support for Nomad and Zot6 removed and only uses ActivityPub anymore while still offering nomadic identity. To my best knowledge, however, it has yet to be declared stable enough to be daily-driven, and it has no public instances.

Other than all this, a non-public development version of @silverpill's Mitra has nomadic identity via ActivityPub in development. I'm not sure whether FEP-ef61 is implemented in the release version yet. It's the only Fediverse project aiming to implement nomadic identity which Mike Macgirvin has nothing directly to do with.

The ultimate goal is to be able to clone a Fediverse identity across project borders. Only considering stable releases, it's currently only possible to clone Hubzilla channels within Hubzilla, using Zot6, or (streams) channels within (streams), using Nomad.

Unfortunately, Mike has officially retired from Fediverse development and only occasionally submits code to the streams repository and Forte anymore.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #DecentralizedIdentity #NomadicIdentity #ActivityPub #FEP_ef61 #Zot #Zot6 #Nomad #Hubzilla #Streams #(streams) #Mitra
joinfediverse.wikiWhat is nomadic identity? - Join the Fediverse
#mitra
Public *
silverpill

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

I fixed proof.verificationMethod values in examples, as well as accompanying text. These values should include fragments that identify a specific key in a DID document, so they are not actually DIDs but DID URLs (a similar change was made in FEP-8b32).
I also added a paragraph on authentication and authorization (with a normative reference to FEP-c7d3), and described WebFinger address reverse discovery in compatibility mode.

Codeberg.orgFEP-ef61: Update proposal- Require path to be an opaque string. - Clarify that custom query parameters should not be used. - Added "Authentication and authorization" section. - Added description of WebFinger address reverse discovery in compatibility mode. - Corrected description of a relationship between proof.verif...
#NomadicIdentity#fep_ef61
Public
silverpill

I'm working on a Rust library for building ActivityPub apps:

https://codeberg.org/silverpill/mitra/src/branch/main/apx_sdk

This code was originally a part of Mitra, but over time I moved re-usable functions into independent packages and then started using them in other projects, Activity Connect and fep-ae97-client. Compared to activitypub-federation-rust, it is a low-level library with fewer dependencies, suitable for both servers and clients. The key feature is support for nomadic identity.

Currently there's no documentation and API is not well designed, but I will be improving it. The license is AGPL-3.0

Forgejo: Beyond coding. We Forge.mitraFederated social network
#fedidev#fep_ef61
Replied in thread
Public
Jupiter Rowland
@Mike McCue If you really want to push it to the limit, here are two suggestions.

@Mike Macgirvin 🖥️ has been a Fediverse developer for 14 years. He has created three Fediverse protocols, he has invented nomadic identity, he has created a whole bunch of Fediverse server applications from Mistpark, today known as Friendica, to Hubzilla to the streams repository to Forte most recently, all forked from each other. He currently maintains the latter two.

He's on (streams) himself, but his channel is still an "old school" one without FEP-ef61 implemented and without its DID scheme.

Also, there is @silverpill, the creator and maintainer of Mitra. Apart from (streams) and Forte, Mitra is the only other Fediverse project that's working on implementing FEP-ef61 and nomadic identity via ActivityPub. Of course, he's on Mitra himself. And unlike (streams), Mitra has switched existing actors to FEP-ef61 on recent versions.

This means that you can not only test Flipboard's compatibility with Mitra, but you can also test Flipboard's compatibility with FEP-ef61 and its DID scheme. Keep in mind, though, that it's still very much a work in progress, and it may change.

Unfortunately, I don't know any (streams) channels with a DID right off the bat that could be interesting for Flipboard. I have two myself, but they're uninteresting.

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #FEP_ef61 #Mitra #Streams #(streams)
hub.netzgemeinde.euNetzgemeinde/Hubzilla
Replied in thread
Public
Jupiter Rowland
@Johannes Ernst
We need to get to identities that aren't tethered to particular instances. Various approaches have been discussed, all more or less valid IMHO, we just need to get them implemented.

We have had one working implementation for 13 years now. In the Fediverse. In stuff that's federated with Mastodon.

@Mike Macgirvin 🖥️, creator of Friendica (2010), creator of Hubzilla (2015), creator and maintainer of the streams repository (2021) and, most recently, creator and maintainer of Forte (all four are being actively maintained, part of the Fediverse and federated with Mastodon), invented the concept of nomadic identity in 2011.

The same year, he implemented it in his own Zot protocol. Zot came to use first in 2012 in a Friendica fork named Red, later the Red Matrix, which became Hubzilla in 2015. Hubzilla still uses the latest stable version of the Zot protocol that's still called Zot. Everything that Mike did since 2012, with the exception of the first Osada from 2018, featured nomadic identity, including (streams) which is based on an "offspring" of Zot called Nomad.

I'm writing to you from a Hubzilla channel that simultaneously resides on two server instances. Not in the shape of a dumb copy, but in the shape of a real-time, bidirectional, live, hot backup.

It's basically what Bluesky has claimed to be a revolutionary new and never-done-before feature in the AT protocol, only that a) it's even more advanced, b) it's older than Bluesky, c) it has been proven to actually work in daily use, and d) it is in daily use.

Right now, Mike is working on implementing nomadic identity using only ActivityPub, specifically FEP-ef61. Even this has advanced beyond theoretical. (streams) has it implemented already. All channels created on accounts that were registered on versions 24.07.20 and newer are made compatible with nomadic ActivityPub. I have two such channels, although neither has a clone yet.

In fact, it could be that at least Forte, which is in a very early stage right now, will have Nomad and maybe even support for Zot6 removed and go nomadic using only ActivityPub. Mike said he wants to sunset Nomad and Zot6 once nomadic identity via ActivityPub is ready for prime time.

@silverpill is working closely together with Mike to implement nomadic identity via ActivityPub on the Fediverse microblogging project Mitra. It has taken the switch to nomadic ActivityPub itself.

Just because Mastodon doesn't have it, doesn't mean it doesn't exist.

CC: @ShadSterling @damon

#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mitra #Hubzilla #Streams #(streams) #Forte #FEP_ef61 #NomadicIdentity
joinfediverse.wikiWhat is Friendica? - Join the Fediverse
#nomadicidentity
Public
Jupiter Rowland
@Fediverse News

The cat is out of the bag. Mike Macgirvin's family of Fediverse server applications has a new member: Forte which he has forked off his own streams repository some three weeks ago.

The first announcement came in a comment on a post about Friendica with which everything had begun, just three days ago. The same day, the up-until-then still unannounced Forte repository was discovered. Unlike what's in the streams repository, Forte seems to have a name again, and Mike refers to it as a "project".

(streams), as its predecessor is colloquially being referred to, is already one of the most advanced and innovative server applications in the Fediverse. It has the most elaborate set of permission controls as of yet, even surpassing Hubzilla, the younger one of its surviving ancestors. Also, Mike uses it to develop the implementation of nomadic identity, his own invention from as early as 2011, purely via ActivityPub, including FEP-ef61. So (streams) itself is already a pioneering work, and its development is far from done.

And now we have Forte which promises to be even more advanced. There are no specs yet, much less any public instances. And even if it's the latest fork in 14 years of Fediverse development, I guess it's far from being ready for prime time. But seriously, it's a (streams) fork.

#Fediverse #NomadicIdentity #FEP_ef61 #Friendica #Hubzilla #Streams #(streams) #Forte
Summary card of repository streams/streams
Codeberg.orgstreamsConsent based public domain federated communications server. Provides a feature rich ActivityPub and Nomad communication node.
#forte
ExploreLive feeds
About