@silverpill@mitra.social avatar

silverpill

@silverpill@mitra.social

Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. Admin of mitra.social instance.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

Is it just me or does every online Monero community feel like a ghost town recently?

The stackexchange is abandoned, the subreddits feel haunted, there are sparse posts that are few and far between with limited and carefully monitored activity, there isn’t much talk about Monero even in general cryptocurrency communities other than the occasional passing mention. Did i miss something? are external factors at...

silverpill,
@silverpill@mitra.social avatar

@DisgracedDoctor @monero @monerobull I think this is because monero today is a boring tool that just works. The community calmed down and many activists/shills moved to greener pastures. This is probably a good thing

If you want more activity in fediverse, you can try to get micro-blogging sector going. There are many people who are interested in monero but no organization. I've seen a couple of accounts run by projects which mostly cross-post from twitter and do not engage with audience. No follow lists. We had a xmrposter Pleroma instance, but it was shut down.

mikedev, to random

For years we've been using an alternate protocol between our own sites because ActivityPub wasn't capable of providing the services we require for federated communications. This is how we've supported things like nomadic identity long before the concept was even viable in ActivityPub. Now that I've got a usable framework for nomadic identity over ActivityPub, I went back and had a closer look at what else I might need to add to ActivityPub in order to finally put the Nomad protocol out to pasture.

I've mentioned transport encryption in the past; but that's only a big deal if you don't trust HTTPS security or your government. For true nomadic identity, we would also be sending sync packets so that your alternate identities are kept up to date with everything you do on other instances which share that identity. We'll also be offering a partially shared identity as mentioned in previous posts. This won't be a true clone but will instead be a way to link your various fediverse profiles in a cohesive way - like we do with our Fediverse Identity Manager. These are all pretty easy - just a 'Simple Matter Of Programming®'.

But I overlooked a real biggie. Permissions, permissions, permissions. A concept completely lacking in ActivityPub; and which can't be discussed rationally with other fediverse developers because folks raised on Twitter don't even understand the concept.

I'm remedying that situation right now.

silverpill,
@silverpill@mitra.social avatar

@mikedev Do you have FEP-ef61 actors already?
I'm still thinking about actor IDs. FEP-ef61 requires new IDs, so existing accounts have to be migrated somehow. I guess it is not an issue for you because you already have working migration mechanism?

strypey, to til
@strypey@mastodon.nzoss.nz avatar

that the @todayilearned bot publishes each new thread on the TIL subReddit to the fediverse.

silverpill,
@silverpill@mitra.social avatar

@Hyolobrika @strypey @raphael

It's all good in theory but in practice "trustless" simply means that trust relationships are obscured. If you want to go trustless you go in the woods and live like hunter-gatherer. In a complex society there is always someone who is running things. The only choice you have is between someone who is close to you (that autocrat who actually might be your friend) and someone who is far away (the developer who is taking VC money and doesn't give a shit about your problems)

Technological tricks that increase your power as a user (key based identity, data portability) can work in both kinds of systems.

silverpill,
@silverpill@mitra.social avatar

@Hyolobrika @strypey @raphael As far as I know Aether and Freenet are single implementations and fully depend on their developers. Only a few people use them so we don't even know how they scale.

IPFS is owned by Protocol Labs, and there are no independent implementations. IPFS will disappear along with Protocol Labs. Also, after all those years it is still too slow for the web and useless without gateways. Torrents is the only system in your list that is truly decentralized. However, they are only successful because trackers exist

silverpill, to random
@silverpill@mitra.social avatar

v2.15.0

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

  • Emoji picker in post editor (for custom emojis).
  • Subscription access without payment. Subscriber status can now be given as a gift, or in exchange for off-site payment (in any currency). To do this, navigate to any profile page and click on "Subscriber details" item in profile menu.
silverpill, to random
@silverpill@mitra.social avatar

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,
@silverpill@mitra.social avatar

@mariusor If a company doesn't serve its customers well, it should go out of the market. And Matrix certainly doesn't serve well, their software has only become worse in the last couple of years.

Insisting that people who don't even use their software should be forced to fund Matrix via taxes? Sorry, but this is unacceptable. For me it's the last straw

silverpill,
@silverpill@mitra.social avatar

@gabriel Yes, state funding is a red flag, even if it comes from innocuously looking proxies like NGI. Just like stewardship by for-profits, this creates a conflict of interest. I generally prefer projects that are maintained by accomplished developers who have other sources of income, or funded exclusively by donations.

silverpill,
@silverpill@mitra.social avatar

@Danbob @monero Congrats. Unfortunately "Follow me" feature (there's a button at the bottom) doesn't work properly.
The popup displays @relay@meetup.events address which can't be resolved. However, @relay@www.meetup.events seems to be working.

silverpill,
@silverpill@mitra.social avatar

I've successfully followed it. Thank you @Danbob

@monero

silverpill, to random
@silverpill@mitra.social avatar

Recommendations for working with nested signed objects (FEP-8b32):

https://codeberg.org/fediverse/fep/pulls/292/files

FEP-ae97 and FEP-ef61 require embedding signed objects into other signed objects (example: Create activity), but Data Integrity specification doesn't say how to do that correctly.

Looks like we have two options:

  1. Use RDF canonicalization instead of JCS, double down on JSON-LD and RDF
  2. Use JCS, but break compatibility with some JSON-LD processors

The proposed change represents option 2 (discussion on SocialHub: https://socialhub.activitypub.rocks/t/use-cases-of-fep-8b32-object-integrity-proofs/3249/18).

silverpill, to random
@silverpill@mitra.social avatar

v2.14.0

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

  • Unicode emoji shortcodes :cat: 🐱
  • Deleting one's own account
  • SVG icons are inlined (UI loads faster, easier customization)
smallcircles, (edited ) to rust
@smallcircles@social.coop avatar

To vendor or to fork? That is the question.

Since Crates.io started giving warnings on the unmaintained status of -rust library, there's a bit of a panic, not in the least because 1,000's of crates depend on it.

This article by the maintainer of Insta snapshot testing tool gives a nice analogy to Collateralized Debt Obligations (CDO's) with considerations on whether you should fork or might vendor the lib.

https://lucumr.pocoo.org/2024/3/26/rust-cdo/

https://github.com/chyh1990/yaml-rust/issues/197

silverpill,
@silverpill@mitra.social avatar

@smallcircles I've read the article but still don't understand what the fuss is about. Looks like Github is harassing open source developers for no reason.

silverpill,
@silverpill@mitra.social avatar

@smallcircles As far as I can tell yaml-rust does what it is supposed to do and there are no known security vulnerabilities. The author published this code under open source license and moved to other things. Everyone was happy...

Until someone from RustSec published this advisory because they believe that software gets insecure if it doesn't change

silverpill, to random
@silverpill@mitra.social avatar

https://help.instagram.com/914046486923176/

>When Threads blocks communication with other servers on the fediverse
>...fails to meet our Community Guidelines...
>We’ll also block a server if it doesn’t have a:
>Sufficient privacy policy; or
>Publicly available policy to restrict access to users under the age of 13; or
>Publicly accessible feed

There are two fediverses. One of them will comply with these rules, and with whatever rules come after that.

silverpill, to random
@silverpill@mitra.social avatar

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.

silverpill,
@silverpill@mitra.social avatar

@giacelvecio I'm also experiencing some issues with the new Hubzilla, for example my likes are rejected (http status 409 is returned). I think this might be related to FEP-8b32 implementation in Hubzilla 9.0

cc @mario

@tallship

silverpill,
@silverpill@mitra.social avatar

@mario Indeed, it worked with your reply.

However, when I like this comment I get 409: https://authorship.studio/item/1aedcbe5-4fe1-4e19-9449-541c99f9e1df

Are likes supposed to be relayed in this conversation?

silverpill, to random
@silverpill@mitra.social avatar

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

With a 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 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,
@silverpill@mitra.social avatar

@greyarea Thanks for the pointers. I probably won't work on this myself, my job is to pick a winning technology and integrate it. The winner is going to be the most resource efficient solution that supports key rotation and has redundancy while being user friendly.

One interesting project that I discovered some time ago just has come to mind: https://github.com/Revertron/Alfis

It is a lightweight blockchain-based naming system without cryptocurrency. Great idea, but it's PoW-based. There is gap between this and regular servers, and I think it needs to be filled.

silverpill,
@silverpill@mitra.social avatar

@erlend No, did:plc is not good, it is just a centralized and vendor-locked version of did:web. Even if they manage to switch to a distributed architecture, fediverse developers should avoid did:plc because it is owned by a company that develops competing social network.

Good Enough solutions are did:web and did:key.

  • did:web is equivalent to what we already have in Fediverse: keys are controlled by instances. But FEP-ef61 separates identity and data, so you can have data portability even though identity is still attached to a single server.
  • did:key is equivalent to what Nostr does: keys are controlled by users
silverpill,
@silverpill@mitra.social avatar

@erlend

did:web is a standard with multiple implementations

did:plc is single implementation deployed on a single server

silverpill,
@silverpill@mitra.social avatar

@erlend The address of the server (https://plc.directory) is written in the specification:

https://github.com/did-method-plc/did-method-plc?tab=readme-ov-file#did-creation

Alternative deployments are not allowed. Even if they remove this requirement, what's the point? did:web is simpler and better

silverpill,
@silverpill@mitra.social avatar

@cmdrmoto @erlend No, DID 1.0 specification doesn't require central directories. Many DID methods depend on some kind of registry, but I think in most cases it is based on distributed ledger technology aka blockchain, so when developers make claims about decentralization, they are not completely untrue.

did:plc is not like that, it is literally a single server, and I have no idea why Bluesky team uses the term "DID". Fake-it-until-you-make-it, I guess.

mikedev, to random

Off to the races...

I've officially started on #NomadicIdentity for ActivityPub. I don't expect it to be nearly as challenging as the work on conversation containers because - well we already have a complete and very mature implementation of nomadic identity. This is literally just translating it to a different wire format.

Well, OK, we also have all these Twitter clones to deal with, that will suddenly be forced to implement real online safety, because they'll quickly learn why we've been rolling on the floor laughing at their primitive whack-a-mole blocking technology.

silverpill,
@silverpill@mitra.social avatar

@mikedev @deadsuperhero Synchronization definitely needs more thinking, but the general idea has been laid out in "Inboxes and outboxes" section: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#inboxes-and-outboxes

When actor creates an activity, it should be sent to all servers where outboxes of actor's clones are located. This can be done by a primary server, or it can be done directly from a client.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • khanakhh
  • magazineikmin
  • thenastyranch
  • Youngstown
  • mdbf
  • rosin
  • slotface
  • InstantRegret
  • tester
  • cubers
  • kavyap
  • tacticalgear
  • DreamBathrooms
  • anitta
  • everett
  • ngwrru68w68
  • Durango
  • modclub
  • ethstaker
  • normalnudes
  • cisconetworking
  • osvaldo12
  • GTA5RPClips
  • Leos
  • megavids
  • provamag3
  • lostlight
  • All magazines
    •