Fedi Meta 

Want to know why we are making an alternative to mastodon ?

Here is what we have in mind parast.at

@impiaaa "also we're making up our own new protocol" i see no issues with that, especially when the people doing that have no experience building that kind of thing afaik

@er1n @impiaaa I've found the blog post that gives a few more details than the landing page:


From the sound of it, they just mean something like LitePub, a version of ActivityPub with some added semantics. Not sure what the progress is on that protocol, though.

The blog post mentions that some of our mod tools "waste time", I'd be curious to hear the specifics and what alternatives they come up with...

@Gargron @er1n @impiaaa "ActivityPub is insecure" is a statement about as truthful as "computer is insecure"

ActivityPub is basically just email with more structured data and less caked-on layers of legacy support.

I'm interpreting this to mean one of two things: either they're designing something with blockchain because they heard that word once and are excited about all the nonsense orbiting around it, or they've got no ideas at all and the project is going to be cancelled when they realize that.

@ben @er1n @impiaaa I don't know all the people mentioned in the project but from what I know I highly doubt a blockchain would be involved. It sounds like the "security" part means OCAPs, which is how e.g. kaniini, who develops LitePub, has been framing it. Personally I am skeptical of what practical benefits OCAPs give, considering that you're still relying on the other server cooperating with the procedure. Which, if that's what you consider insecure...

@gargron @ben @er1n @impiaaa Hello... I think I'm the one that started introducing ocap discourse into the fediverse, though maybe at this point Kaniini has the most attention in terms of the suggested application. Kaniini and I at this point semi-agree on some things: that bearcaps are a viable way to move forward, for instance. However I had objections to the writeup of how litepub suggested using ocaps as not actually being ocap discipline, but we agreed to leave it as an open discussion

@gargron @ben @er1n @impiaaa My main objection, iirc, was that ocaps were framed in such a way as "we'll use this as a way to prevent delegation / sharing of information", whereas one of the ocap tenets has really been that you *can't* mathematically prevent such a thing... so I think that's been a pretty confusing misuse of "ocaps" there. erights.org/elib/capability/de

Nonetheless ocaps *are* useful in terms of actual things: providing an authority model in terms of "what actions can be taken".

@gargron @ben @er1n @impiaaa That *is* a security model, and we can do things with it, eg having the authority to view a post or update a post or curate a collection or have the "parent post" publish your reply to the original recipients, etc. Those *are* security concerns, and one of the main complaints about ActivityPub (rightly so) is that "it doesn't specify an authorization model".

ocaps are a way to do that, but what they can't do (bc nothing can) is prohibit sharing information you have


@gargron @ben @er1n @impiaaa Sorry, and by prohibit I should say prevent.

You can prohibit sharing information (as in, request that it not be done, and if you have evidence that it is done, there are consequences) but you can't prevent the act itself. So I don't agree with the use of "ocaps" to describe such a suggestion, because ocap literature strictly states that that's impossible/wrong.

· · Web · 0 · 0 · 5
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!