If you ask for feedback here you can probably just inline the document?
I haven’t fixed any issues with cryptpad recently anyhow.
This can get quite messy if multiple people send feedback that cover multiple words within the doc. such as if one person has a general comment about a paragraph while another sends proofreading feedback about select sentences within the same paragraph.
1 Like
I like that I don’t need to be the first one to complain about using disgusting,privacy violating Google shit here because it looks like I’m not the only one anymore who cares 
Cryptpad would have been a great choice for this,I use it to write all of my news articles and share the ones which may cause a shitstorm with the rest of the team before publishing them and I think Cryptpad is a great platform for such documents.
Also,if you can’t self-host it for now,then you can use the instance of the German non-profit Digitalcourage e.V. for free with 500MB storage at https://cryptpad.digitalcourage.de ,and later you can still switch to your own.
I can’t say much about the actual content of the document here,as I will never ever click on a Google link,and even if I accidentally did,I have three firewalls preventing me from being stupid 
It would be really helpful if anyone could share a copy of it somewhere else,on Cryptpad or a Nextcloud instance or some Paste service,so that people who care about their privacy can also read it.
1 Like
The problem is with webpositive supporting it, not hosting.
Anybow, I don’t understand why one would need an encrypted (from the servers POV) document for ones that are essentially public. What is wrong with for example etherpad, does that work?
No,Etherpad throws a big red error message saying an error occured, Unhandled Promise rejection.
I also tried in in Otter Browser,there it only shows a blank page,but it seems to work fine in Falkon.
Cryptpad works in none of them,Falkons WebEngineProcess always crashes when trying to load a document,I really expected better results here.
That’s all really unfortunate,but for a document which doesn’t need to be collaboratively edited but only shared in read-only mode,other tools which are less Javascript-heavy should do it as well and work also in Otter Browser and WebPositive.
And there’s also still the old-school way of sending a .docx file as attachment or on some filesharing site,just saying…
Just use free software and things that don’t require creating an account, especially with Google or other big company that make a business of collecting user data. I thought this was kind of obvious in an opensource project?
1 Like
It’s not very clear-cut though, since we rely on a lot of proprietary social media platforms for outreach etc., and the Project also hosts some stuff on Netlify and GitHub, which are proprietary platforms too.
I think the Inc has a Google account too if I’m not mistaken?
Requiring a GitHub account to contribute to HaikuPorts and HaikuArchives is something I also strongly dislike,but at least I can view and download stuff without an account and then I can send my changes using patchfiles or publish them on some random Gitea or get someone to merge them with their account.
Google,however,is a proprietary walled-garden and spyware company of the worst sort and I don’t want to have anything to do with them,not even opening their public pages.
Also we’re heavily locked-in to GitHub already as unfortunately everyone uses it,everything links to it and we can’t switch with low efforts…
Sharing a single document on a friendlier platform is much easier than that.
2 Likes
Yeah, good point. I’m not disputing the fact that we should switch to a better documents platform, but just noting that it’s impossible to use 100% FOSS software, at least in the context of the Project, and promotion efforts etc.
1 Like
Yes,unfortunately it’s sometimes not possible to use 100% free software,but we should try to use free software as much as possible wherever we can.
2 Likes
I am not necessarily happy about that. But at least Netlify can easily be migrated away from, to either go back to old-style real-server hosting, or use another provider. For Github, I would prefer to avoid it, and this is why I pushed for Gerrit to be used instead. But eventually we got Gerrit with Github login. Worse of both worlds!
The Github account was initially just for the website, but then somehow it started getting more and more Haiku stuff.
For Outreach there is a compromise to make of course, you have to reach out to people where they are.
I don’t think anyone said the opposite. But posting something that requires people to create a Google account so they can participate is just going way too far in the other direction. Especially when you could use any “pad” service (cryptpad/etherpad) or if you want something more complex (probably not needed in this case), OnlyOffice online editor would work too.
I use some closed source software for various reasons, but in my Haiku activities I try to not force or encourage people into doing the same, at least. And at every move I make, I try to improve the sitation and not make it become worse than it was in that regard 
3 Likes
Yeah, I hope that can be resolved soon so you can login without a Gerrit account.
It would be good if everything on the GitHub account was mirrored to the cgit instance and vice versa, so people can access the code on either platform.
Actually you don’t need a Google Account to edit - though the restrictions on anonymous editing on mobile (As BlueSky mentioned I think they force you to use the app) are annoying.
That’s not really helpful. The data is freely available on Github without an account and I think most people are fine with that?
The problem is being able to contribute to the projects, and for that, a Github account is currently needed on both sides anyways 
And having two completely different ways to submit changes would not be practical at all.
2 Likes
Hi, I’d like to issue a correction here. I did take an issue with it, but still ended up agreeing to use it, due to the lack of a better alternative. I brought up the prospect of establishing a cooperative “pad” for internal usage, as well as trying to use certain tools hosted by @PulkoMandy. Unfortunately, that idea fell stale, as I have no idea how I could possibly put my money where my mouth is.
Cryptpad is great, and I think that, if we are to use something not hosted by ourselves, using something hosted by a well-known, EU-based, non-profit entity is much better than nothing.
2 Likes
From personal experience: This is absolutely doable and exceptionally useful during a transition period. However, this requires people that are familiar with both platforms, and some changes may go unreviewed as a result of the person who’s capable of reviewing it not being able to use the platform chosen by the contributor.
1 Like
Sidenote: I think we ended up fixing our problem regarding working on documents collaboratively without using closed-source software with Matrix and an Etherpad widget for the channel, since the most engaged of us have already moved to that protocol anyways. We’ll use it for a bit and establish if it’s good enough, then I’ll include the Etherpad link in the channel description for the IRC/XMPP peeps after I think about some stuff such as permissions and how we can manage having multiple pads at the same time for organization (which is possible and should be relatively easy). :D
1 Like
Etherpad widgets are an “element” exclusive feature, you can hardly call this a matrix festure, the only thing matrix provides is the accounts thus forcing you to use a matrix account for this while etherpad works fine standalone, and forcing you to use element (which is a web app)
No, you can’t have multiple pads in a single channel iirc.
And also IRC and XMPP are not the same thing, please don’t treat it as such, if anything XMPP is the more sane between matrix and XMPP.
And also IRC and XMPP are not the same thing, please don’t treat it as such, if anything XMPP is the more sane between matrix and XMPP.
I’m not sure where I specified that.
Etherpad widgets are an “element” exclusive feature, you can hardly call this a matrix festure, the only thing matrix provides is the accounts thus forcing you to use a matrix account for this while etherpad works fine standalone, and forcing you to use element (which is a web app)
Well, Etherpad, including the widget-created documents, can still work standalone on a browser the same way Google Docs does, I just felt that it was a bit neat to have an additional possibility that wasn’t previously there. There’s arguably still a degree of integration with the Matrix channel (see the URL of an Etherpad). If you have any better alternatives or serious reasons to not adopt this alternative like that, do let me know and we’ll change it up, but I’m seriously trying to avoid a Bikeshed-type of situation over here and do my best to get rid of what we previously had in place. That’s why I’m being transparent about this.
I’m not sure where I specified that.
In this situation, however, they are, in the sense that the ecosystem surrounding them does not integrate anything like that straight into their product. The only fallacy in what I said was that, even if arguably most people that use Matrix also use Element, this does not apply to the Haiku ecosystem. I’m a fan of gradually rolling out things before figuring out that they don’t work instead of giving everyone something new and then taking it away from me – although I should’ve probably led with putting an Etherpad link in the description first, instead of following an approach that isn’t Haiku-first.
Either way, this sort of integration is more of a neat “huh, nice, I didn’t expect that!” that we wouldn’t otherwise get with, say, Google Docs, and not something that hinders collaboration in any particular way. I already had Etherpad in the back of my head, as other teams developing free and open-source software that I’ve been tangentially involved with, which predominantly used IRC as a tool of real-time communication, also used Etherpad and/or similar solutions and it seemed to work.
Just use etherpad without the matrix box around it…?
I specifically asked before whether etherpad works in WebPositive, I did not get a response to that.
The “product” is not matrix, it is a specific matrix client and basically the worst there is, the widgets are literally just wrappers around websites, if your argument is “XMPP does not force you to use a webrowser” I think we can stop here.
Element widgets are basically impossible to support in other matrix clients without including a webrowser, this is not really an integration either, it does not use matrix for anything aside from new vector hosting the etherpafd instance for you (and the matrix accounts for auth), in essence it is a cheap trick to say “matrix supports ” while using readily available software for that usecase and tricking you into having to work in an iframe.
This is what I was reffering to:
Exactly, matrix and irc are unrelated to this, so please don’t force a matrix centralized solution for no reason.
1 Like