"Get started for free" - warning enough.
We were focused on making it work first, and thanks to your feedback we'll make it great.
91–100 of 240 posts
"Get started for free" - warning enough.
We were focused on making it work first, and thanks to your feedback we'll make it great.
This is interesting and (like everyone else) I have a few questions: - Will this be based on open, industry standard protocols? - It looks like there are multiple applications combined into one giant system in the web- and Android apps right now. Will those be interchangeable (with say, third party implementations)? Are the apps somehow connected (do the music player and the gallery for example get their content from…
This is interesting and (like everyone else) I have a few questions: - Will this be based on open, industry standard protocols? - It looks like there are multiple applications combined into one giant system in the web- and Android apps right now. Will those be interchangeable (with say, third party implementations)? Are the apps somehow connected (do the music player and the gallery for example get their content from…
(2) You can see current Bloom as an Unikernel, So yes the music player and the gallery lets you play files directly from your Drive :)
One things like oauth will be implemented I see no constraint to use third party implementations (planned for Q4 2019).
(3) Totally, Better self hosting documentation is planned for next version: https://gitlab.com/groups/bloom42/-/epics/5
In order to compete, I think it's important that there is some way to import existing data from competitors (read: Google). I would like to switch to try it out, but I don't want to spend several hours uploading or manually entering data.
it's planned (but no precise date) after the Beta :)
I like what you're trying to do and definitely something id use when it's more mature. Not a comment on the quality or feature set, i just like to know tech isn't going to stop being supported after I spend time migrating to it. I do have to say though that I think you're really setting yourself up to underwhelm with that Google comparison. Google is absolutely a search engine first and foremost in everyone's minds.…
Regarding Google, and after all these comments maybe 'Apple' is more accurate.
Earlier quoted context omitted.
Hi, currently we absolutely do not plan to create a search engine: it requires too much resources for self hosting, I think we currently have great option for all the spectrum (From Google search to DuckDuckGo), and because an open source search engine will be tricked by all kind of nasty SEO Experts and it will be very hard to promote actually good Content. I dared the Google comparison thinking about it's productiv…
>great option for all the spectrum (From Google search to DuckDuckGo) You probably mean from SearX to YaCy.
This is interesting and (like everyone else) I have a few questions: - Will this be based on open, industry standard protocols? - It looks like there are multiple applications combined into one giant system in the web- and Android apps right now. Will those be interchangeable (with say, third party implementations)? Are the apps somehow connected (do the music player and the gallery for example get their content from…
(1) Currently not really, we have a (self made) HTTP API, and S3 API support for blob storage. We don not support (and do not have yet examined things like WebDAV...) (2) You can see current Bloom as an Unikernel, So yes the music player and the gallery lets you play files directly from your Drive :) One things like oauth will be implemented I see no constraint to use third party implementations (planned for Q4 2019)…
Wow! Yes! Awesome! I will happily pay twice as much as I do/would for any given google service if it means this survives. If there could be a "sign in with bloom" on every site, that would be great. I would be happy to donate for email for something like this as well. I really want an email service that isn't gmail. God I just hope non-technical people can be made aware of and interested in this, because it would be…