Self-host for syncing!

[vdbhb59]

Hi Mate,
Just want to understand a possibility of having self host feature for syncing.

[sakethpathike]

That’s definitely going to be implemented, but it may take some time to get started on it.

[plutonium-239]

I can try to help implementing this.
Since the data can easily be exported in json (great decision), it should be easy to hook it up to existing file sync services and make a web front end for displaying the same things.

Does the json schema change in updates? (Or is it expected to not change, now that the app has taken shape?)

[sakethpathike]

@plutonium-239

Since the data can easily be exported in JSON

The problem with JSON here is that the targeted service likely won't use the same schema as Linkora, meaning they’d need to write a custom import implementation for this app, or we'd have to change how it's implemented in Linkora.

I'm thinking of dropping JSON exports since HTML is a standard and supported by most browsers (#16). This could be an advantage, plus Floccus also uses HTML. This way, both self-hosting and import/export can be improved, while supporting "cross-platform" sync.

Imports will still be supported for both JSON (which will stick to the Linkora schema) and HTML.

Does the JSON schema change in updates?

It won't be changed :)

[plutonium-239]

I would argue that json is much more cross platform and easily understandable from a dev perspective, no one wants to do html parsing. json is very effective at representing data

So keep both maybe?

[vdbhb59]

Also, please allow manual or non-docker implementation. Docker is a big pain tbvh.

[sakethpathike]

@plutonium-239

I would argue that json is much more cross-platform and easily understandable from a dev perspective.

json is very effective at representing data.

It's not about understanding but more about compatibility with other similar services. As long as the custom hosting exists only for Linkora, it won't be a problem, but the moment anyone wants to import from other services or export to other services, it raises the compatibility issue, which can only be solved if every similar service can understand the schema/export format of each other.

no one wants to do html parsing.

But this seems to be the solution, as every similar service can understand this format.

So keep both maybe?

Yeah, this should be a better option.

[sakethpathike]

@vdbhb59

I finally have an update after 2 months lolll

Also, please allow manual or non-docker implementation. Docker is a big pain tbvh.

I'm currently working on the server (https://github.com/LinkoraApp/server) and will publish it as a JAR file, which requires Java 11 or higher installed on the PC. I’ll also release a Docker image alongside the JAR file, so you can choose either based on convenience. The server can be configured externally for credentials, database passwords, and similar settings.

You’ll need a database installed on your local machine, as the server will connect to it for all data operations.

I'm currently testing it with MySQL, but it should work with other SQL-based databases as well.

[vdbhb59]

I have Debian 12 with most dbs on sqlite, as I hardly use MySQL. I will wait this one out. Thanks for the update, and remembering me, mate. :)

[plutonium-239]

If the exported data is already json, why do we need a SQL db?

[vdbhb59]

My bad on that. Ignore that part. :)

[plutonium-239]

I was asking the maintainer lol

[sakethpathike]

@plutonium-239

If the exported data is already json, why do we need a SQL db?

Database is much more flexible than a typical file system. Linkora does use JSON/HTML exports/imports just to make sure data is portable to other services, but now that the custom hostable server is capable of handling everything (the data part), a database is just a better option and it scales like butter. If that's done with a file system, it's going to take a ton of time just to parse the file for every request, which sucks.

Also, you don't want to parse everything for every single request that has something to do with data.

[vdbhb59]

In that case do keep sqlite as default option.

[sakethpathike]

@vdbhb59

If I embedded that, then you'd lose the data if you accidentally deleted the JAR file lolll. But the external database, which runs on your machine, won't be affected if the server file is deleted. Later, if there are updates to the server, you can connect to that database as usual without losing any data.

SQLite can be used, as I mentioned before, but it won't be embedded within the server.

[vdbhb59]

Gotcha. In that case, my suggestion would be to use something like Forgejo does. It is implemented internally, with an option for user to set a database path via its environment file.
Forgejo

`

[database]
DB_TYPE = sqlite3
-- optional if you want to specify another location
-- by default, the database file will be stored relative to other data
PATH = data/forgejo.db

`

`
//go:build sqlite

// Copyright 2014 The Gogs Authors. All rights reserved.
// SPDX-License-Identifier: MIT

package setting

import (
_ "github.com/mattn/go-sqlite3"
)

func init() {
EnableSQLite3 = true
SupportedDatabaseTypes = append(SupportedDatabaseTypes, "sqlite3")
}
`

db_sql_go

[sakethpathike]

@vdbhb59

Linkora server does a similar setup on first run, you'll need to provide database path/URL and its credentials, which will be saved in an external file created by that setup and will be used further.

I'll make a dedicated blog/video on it once I implement client side handling in Linkora app.