Fedi Meta 

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

Here is what we have in mind parast.at

#FediAdmin #MastoDev

@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:

parast.at/blog/2020/01/03/what

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...

@Eugen @Christopher Lemmer Webber OCAP is just one way to implement permission checks. While I was a bit disappointed that the engineering tradeoffs of different permission mechanisms weren't given much consideration (they all have certain strengths and they *all* have major flaws which must be addressed), I've implemented OCAP as a permissions mechanism for ActivityPub communications in my current project and it's not difficult. It still federates fine with Mastodon and Pleroma. End users don't care about the details. They just want it to work.
Follow

@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.

· · Web · 1 · 0 · 0
@Гришка  We did it this way so it could be easily versioned - because these contexts change; and if you're talking to servers of the same platform with different versions you need one specific to that server.

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.
Sign in to participate in the conversation
Mastodon

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!