Follow

Fedi Meta 

Fedi Meta 

Fedi Meta 

@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 @gargron @er1n @impiaaa "Crowdfunding campaign" is where I yelled "Bingo" and closed the browser.

Yeah, good luck with 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 @er1n @impiaaa OCAP isn't a security technology, it's an implementation detail

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

@cwebber @Gargron @ben @er1n @impiaaa as far as i can tell, the project is actually treating activitypub similarly to how mastodon 2.x supported ostatus even after adding activitypub.

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

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

@Гришка  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.

@ben @er1n I'm pretty sure the authors are against blockchain, so it's definitely the latter case (just like with forkoff/florence)

@impiaaa @er1n Florence at least had concrete goals

this project seems to be a fundraiser scam with no actual plan to make a piece of usable software

@ben if it had goals it certainly did not make them known

@impiaaa they claim Mastodon takes 2GB of memory just to start up, and my instance is currently using less than 200 megabytes

they claim 64 megabytes of memory for 1000 users, which I can only assume means 1000 users who are all logged out

they've also got a screenshot of their "great design" which appears to be a nonfunctional mockup, but for some reason the posts are not in chronological order and also every single one of the mocked-up posts is more than 2 months old

@ben @impiaaa @er1n it’s okay for you to not believe the project but I won’t let you accuse my friends of being scammers. They have concrete goals and there has been actually months of work and personal investment before making themselves public. There are already prototypes running.

@ben @impiaaa @er1n the interface prototype is only a mockup, but internally it’s already mostly written in Elm, they’re currently implementing it to the software

@gargron @er1n @impiaaa CNPL... license with nice goals, but I think they'll find fairly quickly that compliance turns out to be hard.

@cwebber
this site is written with to much emotions throwed against others and it reads like there is nothing except the idea to get some money.

furthermore this licence is kinda strange and because of risks with possible law problems no serious domain owner will accept it for a service he is personally responsible for.

Gargron, continue your good work and try to open @Gargron @er1n @impiaaa - 1/2

it to more people. this "i do not like you or your lifestyle so you are not allowed to enter fediverse" brought up by some is the only thing which can stop growing the hard way.

@Gargron @er1n @impiaaa @cwebber - 2/2

@Gargron pretty sure there's a whole ton of ideas rotting in your issue tracker bud
@er1n @impiaaa

For people reading this who would like to contribute to an *existing* fediverse software project that is not Mastodon, try these:
• The glitch-soc fork: github.com/glitch-soc/mastodon
• Misskey: joinmisskey.github.io/
• microblog.pub: microblog.pub/
• Kibou: git.cybre.club/kibouproject/ki
• Dolphin: github.com/syuilo/dolphin
• Rustodon: github.com/rustodon/rustodon
• Pleroma: pleroma.social/
• GNU Social: gnu.io/social

@Spencer Alves There are many more. We don't expect a lot of people to know about Zap since it is being built outside a marketing/consumer culture. But Friendica and Hubzilla have been around for years and have very vibrant development teams. Even then, there are still  many more. Those are just the ones I know of.

@impiaaa the Cambrian explosion of diversity in the ActivityPub ecosystem is an indicator of healthiness. It's nice to see *another* one.

Fedi Meta 

Fedi Meta 

@parastat i'm strongly interested by both the security/moderation upgrades and the design one you're announcing.

Is there anyway i could contribute ?

@Oz I'm sure there are many, many, way you could help the project.

Development, documentation, donation, openning bugs, testing, peer review, translation, talk/write about the project, security audits, making apps etc. etc. are all healthy ways to participate.

It is not yet obvious how, but we will be in touch soon with ways to do just that :)

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

re: Fedi Meta 

License questions 

License questions 

Sign in to participate in the conversation
Octodon

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