►
From YouTube: Jan 19, 2023 - Ortelius Architecture Meeting
Description
In this meeting, Steve Taylor covers the new architecture for Ortelius including work with XRP Blockchain and potential integration with RedHat OCI Emporous.
A
A
A
C
A
So
some
of
the
other
pieces
that
will
be
working
with
are
we'll
need
new
microservices
and
actually
some
of
the
existing
ones
will
have
to
change
slightly,
but
mostly
it'll
be
a
new
microservices
that
we'll
need
to
use
to
replace
the
transactions
that
we
have
in
the
monolith.
There's
not
a
lot
of
overlap,
so
it'll
be
more.
A
A
A
You
basically
get
this
hash
they're
based
on
location
and
not
on
name.
So
you
get
this
Sid.
That
says
this
is
where
this
data
lives,
but
you
know
nothing
about
the
data.
That's
there.
So,
with
a
combination
between
The,
Ledger
and
nfts
I
believe
we
can
build
a
searchable
cache
and
kind
of
the
idea
that
I
have
is
the.
A
All
the
data
that's
going
to
be
in
ipfs
will
be
normalized,
which
means
like
for
I
keep
on
coming
back
to
the
license
object.
So
if
you
have
a
s-bomb
that
says
this
package,
you
know,
click
for
python
is
an
Apache
2,
and
then
we
have
another
package
for
like
Fast.
Api
is
another
package
that
may
be
Apache
to
we're
only
going
to
store
the
Apache
2
license
once
in
ipfs
and
both
of
those
s-bombs
are
going
to
point
to
that.
A
So
that's
what
I
mean
by
a
normalized
database,
so
we
we
remove
duplication
as
much
as
possible.
One
of
the
things
and
what
that
allows
to
do
is
is
take
to
minimize
the
amount
of
data
that
we're
storing,
because
when
you
look
at
the
s-bombs
and
all
the
the
data
that
we're
collecting
there's
a
lot
of
repetitiveness
in
it.
So
when
you
look
at
the
Deltas,
the
Deltas
actually
are
pretty
small.
A
To
do
that,
it
seems
the
most
flexible
I
did
look
at
the
other
one
at
Tony
suggested,
and
they
want
more
of
a
full
on
schema
to
be
able
to
do
what
we
need
to
do
and
I
think
that's
just
going
to
be
too
restrictive
at
that
level,
and
the
idea
is
when
you
go
in
the
front.
End
needs
some
data.
It'll
go
and
search
through
the
cache.
The
cash
will
then
give
us
the
the
location.
A
Let's
say
we're
looking
for
the
details
about
an
application,
the
applic
that
will
go
ahead
and
give
us
the
the
Sid
to
the
application,
and
then
we
have
to
go
through
and
denormalize
it.
So
denormalizing
is
pulling
all
the
pieces
together
back
into
one
big
document
and
then
that
document
we
would
actually
store
in
the
Rango
DB.
So
if
we
need
to
get
to
that
application
again,
then
we're
going
to
go
ahead
and
use
the
one
as
cached
at
that
level.
A
So
that's
that's
kind
of
the
concept
behind
it
and
this
concept
will
also
be
able
to
be
applied
to
the
oci
registry
as
well.
So
the
Durango
DB
is
really
like.
You
can
think
of
as
an
ephemeral
database
which
we
go
through
and
recreate
everything
from
The
Ledger
and
the
ipfs
to
create
the
cache,
the
searchable
cache
and
then
from
there
we
kind
of
bring
things
up
as
we
need
it.
A
This
is
one
of
the
things
when
you
look
at
when
people
use
ortilius,
UI
they're,
looking
at
a
small
subset
of
all
the
data,
that's
out
there,
so
we
don't
need
to
have
everything
right
there
available
all
the
time
you
can
kind
of
think
of
it
as
like.
A
fast
disk
versus
slow,
Disk
type
of
access
and
the
caching
will
help
us
move
things
between
the
slow
and
the
fast
area.
A
Now
we've
been
meeting
with
red
hat
around
the
oci
registry,
specs
that
they're
going
to
introduce
they
don't
have
any
documentation
on
it
yet
on
what
their
new
extensions
or
plugins
are
going
to
be.
But
what
I'm
thinking
is
that
oci
registry
would
be
treated
similarly
as
the
nft
storage,
where
we
would
go
ahead
and
make
the
searchable
cache
telling
us
where
in
the
registry,
you
need
to
find
things
and
I
believe
the
registry
may
have
some
transactional
history
kind
of
late,
The
Ledger
we'll
have
to
see
on
that
front.
A
I'm,
not
100
sure
what
capabilities
are
gonna.
The
oci
is
going
to
have
to
give
us
a
transactional
history
of
how
things
evolve
over
time
for
an
object,
I'm
pretty
sure
it's
there.
We
may
have
to
do
some
extra
work
to
to
build
that
out,
but
the
same
idea
is
we'll
be
doing
the
searchable
cache
and
then
the
ephemeral
database
for
the
documents
at
that
level.
A
A
A
A
Just
based
on
some
of
the
like
prototyping
I've,
been
doing
like
these
two,
where
we
have
a
service
for
creating
doing
a
create,
update
or
delete.
Then
another
service
for
the
just
for
the
read
I
think
we'll
be
able
to
combine
these
the
arango,
DB
and,
and
some
of
the
layouts
in
Python
aren't
too
big.
So
it
doesn't
look
like
we're
getting
a
huge
massive
microservice.
A
So
the
number
of
microservices
Will
basically
go
in
half
here.
One
of
the
things
I
did
introduce
was
tagging
a
component
tag,
an
application
tag.
I
have
not
heard
anything,
I,
don't
know.
If
he's
on
the
call
today,
if
Nick
is
here
from
Ukraine
now
it
doesn't
look
like
it,
but
we
may
need
tagging
in
order
to
do
some
of
the
additional
searching
and
UI
layout.
A
So
I
added
that
in
there,
basically,
if
you
think
of
like
Docker
Hub
or
even
like
npm
dot
org,
you
can
tag
things
and
say
this
is
a
a
login
method,
or
this
is
going
to
be
a
compression
function
that
that's
the
type
of
tagging
I'm.
Thinking
that
we
may
be
able
to
use
to
help
find
things
in
the
in
the
database
ignore
this
down
here,
because
I'm
going
to
go
over
to
another
document.
B
A
B
A
A
Components
here
so
some
of
the
things
that
when
we
lay
out
a
component,
this
is
mostly
this
data
structure
is
coming
from
the
postgres
database.
For
the
most
part,
I
did
take
the
opportunity
to
reorganize
some
things
slightly
to
just
make
it
a
little
more
efficient,
and
these
classes
and
objects
are
going
to
be
what
the
UI
front
end
is
going
to
consume.
A
A
That's
like
pretty
much
all
that
we
need
in
the
list.
So
this
is
like
the
example
here
where
we
have.
The
hello
world
is
the
name
and
the
in
the
domain
that
it
lives
in
there's
other
things
that
we
have
to
provide
like
the
parent
and
parent
I,
the
parent
of
the
component
version
things
like
that,
so
this
will
be
pretty
close
for
the
list
and
same
thing
like
with
the
application
version.
A
Basically,
it's
like
the
the
the
name
and
the
domain
from
there
if
we
actually
look
at
an
individual
component,
so
when
you
go
into
in
the
UI,
you
click
on
a
from
the
list
view
you
click
on
an
actual
component
version
to
dive
into
the
details
we
actually
inherit
from
the
previous
one.
So
all
that
the
name
and
stuff
like
that
comes
from
there
other
things
that
we
need
to
have
are
like
the
owner,
the
Creator,
the
type
packages,
basically
the
s-bomb
data.
A
A
We
have
a
readme
the
list
of
applications
that
are
consuming
this
and
then
like.
What
is
this
component
version
provide
for
restful,
API,
endpoints
and
what
it's
consuming,
and
then
we
have
our
attributes.
Our
attributes
are
all
the
key
value
pairs
that
we
have.
One
of
the
things
on
the
audit
log
I
was
looking
at
I
think
this
is
going
to
probably
change
I
have
to.
A
We
have
to
play
it
out
because
this
will
be
coming
from
The
xrpl
Ledger,
for
example
the
audit
Trail,
so
it
may
or
may
not
be
Associated
to
this
I
have
to
look
at
that.
So
when
you
look
at
the
Json
after
it's
all
expanded
out,
you
have
your
name,
your
owner
information,
the
packages
that
you're
dependent
upon
the
vulnerabilities.
A
You
read
me
your
attributes,
all
your
attributes
and
stuff
like
that,
and
this
is
one
of
the
reason
why
I
chose
a
Rango
over
some
of
the
other
graph
databases,
because,
like
this
part
here
around
the
attributes,
it
can
be
free
form.
So,
if
we
want
to
add
in
like
the
committers
username,
we
can
add
that
into
this
list
without
having
to
go,
redefine
the
schema.
A
So
as
people
go
through
and
and
add
in
their
own
attributes,
we
can
actually
just
you
know
on
the
Fly,
not
have
to
worry
about
changing
database
schema
and
just
go
ahead
and
consume
them
at
that
level,
and
then
you'll
see
we
have
application
version.
So
I
pretty
much
all
of
the
objects
out
here
that
we
need
and
examples.
So
if
we
actually
go
over
to.
A
A
This
all
just
is
a
the
object,
that's
coming
across
from
the
front
end
in
Json
format
and
then,
when
we
go
to
save
it
to
the
database,
we'll
transform
that
that
object
into
the
normalized
version
break
it
out
into
all
the
little
pieces
and
shove
it
into
ipfs
or
oci
in
the
right
locations
and
then
add
it
to
the
the
Rango
database
in
like
its
full
format
at
that
level.
So
if
we
look
at
the.
A
A
So
the
key
is
basically
a
string
and
we
may
be
able
to
use
the
ipfs
Sid
for
the
key
which
will
help
some
of
the
searching
and
things
and
simplify
some
stuff
a
little
bit
up
in
there
still.
So,
when
we
look
at
the
get,
we
can
actually
see
the
example
coming
back
of
all
the
data.
That's
going
to
be
passed
back
to
the
front
end
at
that
level,
so
I'm
going
to
go
ahead
and
build
out
the
stubs
for
the
other
restful
apis.
Like
I
said
it
doesn't
look
that
bad.
A
A
A
From
that
that
perspective,
so
that's
kind
of
what
I've
been
working
on
and
giving
us
I
will
create
a
PR
for
the
architecture
here
once
I
get
a
little
bit
further
along,
hopefully
next
week
early
next
week,
I'll
have
the
pr
out
there
for
us
to
actually
approve
and
make
sure
and
comment
on,
and
things
like
that
to
make
sure
we
have
everything
covered
at
this
point.
So
that's
it
for
the
the
presentation
and
if
anybody
has
any
questions,
let
me
know
a
lot
to
cover.
B
A
A
The
idea
behind
Google
material
is
to
create
these
components
these
web
components,
so
you
can
think
of
as
widgets
that
you
get
to
reuse
and
stick
on
the
UI.
They
went
through
a
lot
of
research
on
the
the
component
widgets,
so
you
know
a
if
you
want
to
draw
a
box
with
curved
Corners.
They
have
spec
on
what
the
radius
of
the
curved
corner
is
supposed
to
be.
I
mean
they
went
crazy.
A
A
A
A
C
A
It'll
need
to
be
in
its
own
container
and
that's
where
we
could
possibly
even
containerize
it
a
little
further
down
the
road
where
we
can
container
like,
especially
with
the
riot
one.
We
can
containerize
those
individual
component
widgets.
So
if
we
want
to
go
out
and
replace
or
update
a
component,
we
can
do
it
that
way,
because
it's
it's
kind
of
more
like
on
the
Fly
I,
don't
think
it's
compiled.
C
A
A
You
can
have
two
different
versions
running
at
the
same
time
and
you
can
actually
use
istio
to
pick
which
one
you
want
to
go
to,
so
the
dev
side
could
be
picking
up
the
new
version
of
the
container
with
the
new
color
of
the
component,
where
the
production
one
is
still
using
the
old
container
and
as
you
go
through
and
do
your
testing
you
can
actually
then
basically
do
a
istio
switch
on
the
virtual
routing
to
say.
Okay
now
this
is
the
new
container
I
want
you
to
use
for
production.
A
C
D
D
F
D
F
A
D
So
that's
really
important.
I
want
to
start
with
the
backstage
this
time,
because
there's
a
lot
of
or
a
lot
of
a
lot
of
noise
coming
in
the
backstage,
so
I
want
to
have
some
content
on
that.
So
please,
please
circulate
some
emails,
so
we
are
up
to
19th
of
January
and
haven't
doing
any
podcasts,
so
I'm
waiting
for
some
guest,
okay.
D
A
C
It's
to
get
developer,
it's
a
developer
environment,
I,
don't
know
what
is
a
good
I
call
the
tortillas
in
a
box,
but
it
doesn't
have
to
be
called
there,
because
that
doesn't
really
make
sense.
Anybody
I'm,
of
course,
you're
a
developer.
What
makes
sense
to
you
if
you
were
joining
an
open
source
project,
I'll.
C
A
I
did
at
the
just
to
give
you
an
update.
I
had
to
I
did
submit
to
GitHub
our
application,
the
contract
for
the
GitHub
sponsorship,
so
we
can
get
paid
through
GitHub
for
working
on
issues.
I
haven't
heard
back
from
them,
yet
I'm
going
to
see
if
I
can
get
some
help
from
the
Linux
foundation.
On
that
front,
it's
kind
of
a
black
box
when
you
talk
to
GitHub
as
a
small
company
yeah.
C
A
A
B
A
A
A
If
we
do
the
back
end
work
correctly,
that's
what
I'm
hoping!
Oh
you
never
know,
but
that's
that's
the
goal.
So
I
will
once
I
get
this
architecture
document
out.
There
I'll
start
going
in
assigning
issues
to
folks,
so
people
know
what
they
can
start
work
out
or
you
know,
throw
out
a
list
for
people
to
pick
and
choose
of
what
what's
on
the
short
term
list
that
we
need
a
code.
A
B
F
E
A
B
F
A
F
B
G
G
B
B
F
F
A
A
At
least
at
least
for
some
of
the
transactions
I
think
you
know
we
may
not
have
every
single
object
being
pushed
back
and
forth,
but
kind
of
starting
at
the
lowest
level,
which
would
be
component.
Inversions
are
kind
of
like
the
lowest
level
objects
that
we
have,
because
then
you
know,
application
versions
consume
those.
So
that's
why
I've
been
focusing
mostly
on
component
versions.
A
A
I
think
most
of
it
will
be.
Oh
there'll,
be
two
two
types
of
data
that
will
we
basically
retrieve
is
one's
a
list,
and
the
list
is
basically
like
I
said
just
just
like
name
and
domain
are
in
the
list,
and
then
we
have
the
detail.
So
it's
really
like
two
types
of
transactions
that
we
have.
Oh
and
then
the
other
one
is
gonna,
be
the
graphing.
You
know
dependency
to
dependency
graphing.
A
And
and
data
wise
I
think
because
we're
going
to
be
using
a
Rango
as
just
a
an
ephemeral
database
that
will
kind
of
populate
on
the
fly
from
ipfs
and
The
Ledger
that
we
should
be
able
to
to
minimize
the
amount
of
data
that
we
are
going
to
store.
I,
don't
think
we're
gonna
have
to
worry
about
in
the
orango
database.
Dealing
with
like
a
terabytes
of
data,
I
think
it'll
be
relatively
low
in
the
gigabytes.