Fedi Meta
Want to know why we are making an alternative to mastodon ?
Here is what we have in mind https://parast.at
*another* one? oof.
@impiaaa "at least this one is pretty"
@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:
https://parast.at/blog/2020/01/03/what-is-parastat.html
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. http://www.erights.org/elib/capability/delegations.html
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.
@mike a bit of off-topic: I received this post on my server (because I follow Eugen) and got a bunch of errors in my log because of a remote JSON-LD context URI that my server doesn't know about.
Is there a good reason to use instance-relative context URIs? I don't want to do any networking in my JSON-LD processor for performance reasons so I match URIs against a set of known ones and use a predefined context from cache. This fails miserably in such cases.
This work was done long before Mastodon started using inline contexts. I suppose we could do that, but I still recommend a context file cache. We had a long debate about this at the time as even the core ActivityStreams context can change and signatures will fail if that change isn't backward compatible. A pointer to dated contexts was recommended but this failed when using with Mastodon and I've never investigated the reason. LD signatures is a disaster, but we've all tried to find a way through the major land mines. This was our way.
Server run by the main developers of the project 
It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!
@Gargron @er1n @impiaaa OCAP isn't a security technology, it's an implementation detail